Subject: Re: PaceIntrospection: Is another file format really needed?

From: Danny Ayers <[email-masked]>
Date: Wed, 30 Jun 2004 17:09:33 +0200

Ken MacLeod wrote:

> To me, atom:feed is a syndication feed.  Extending it to an
>index/archive format has shown its weaknesses for general tasks (which
>feed headers are the "main" ones?  why do the rest need all the
>required elements when they could point to a site or category origin?)
>  
>

Yep. Overloading atom:feed would only add to confusion, it's already got 
a lot of potential for confusion when people are used to seeing more 
static documents.

>Entries are being forced to be both log entries and metadata wrappers,
>and they're pretty oddly defined metadata wrappers.
>  
>

I like the idea of an entry being comparable to media that carries 
embedded metadata. There's some structural stuff in the file, there's 
the content and there's the metadata about the content. Given that we're 
using XML on the web it does make it easier to point to non-embedded 
things (even the content), but I think the general idea of atom:entry as 
content+metadata parcels works well. If other parcels are needed for 
introspection of whatever then I think something other than atom:entry 
would be more appropriate.

>>Once again, it's all a matter of doing the simplest thing that could
>>possibly work.
>>    
>>
>
>There are two parts to the DTSTTCPW rule: 1) implement a new
>capability in the simplest, then 2) refactor.  [1]
>
>You don't get a chance to refactor much after you've published a
>public format or protocol.  DTSTTCPW only applies during the iterative
>development phase before final release.  This is why we must pay
>attention to long term use and extension.
>  
>

Right, thanks for saying that, it bugs me like talk of YAGNI here has 
done before - these development patterns work for implementations, but 
not necessarily specifications. Different game, different rules.

Cheers,
Danny.

-- 

Raw
http://dannyayers.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 30 Jun 2004 20:58:20 +0200

On Wed, 30 Jun 2004 17:09:33 +0200, Danny Ayers <[email-masked]>  
wrote:

> I think the general idea of atom:entry as content+metadata parcels works
> well.

+1.

> If other parcels are needed for introspection of whatever then I think
> something other than atom:entry would be more appropriate.

+1. Different purposes, different elements, models and constructs. There's  
no real point in reusing atom:feed and atom:entry if what we're trying to  
do with them is totally different from the element's original purpose.

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Beecher Greenman <[email-masked]>
Date: Wed, 30 Jun 2004 22:58:00 -0400

Asbjørn Ulsberg wrote:

> +1. Different purposes, different elements, models and constructs. 
> There's  no real point in reusing atom:feed and atom:entry if what we're 
> trying to  do with them is totally different from the element's original 
> purpose.
> 
Except that introspection exactly fits the element's original purpose. I 
offer the following as proof:

----------

 From the ConceptualModel article in the Wiki, at 
http://www.intertwingly.net/wiki/pie/ConceptualModel:

feed, channel:
     Definition: A collection of resources in an order.

entry
     Definition: An entry is a metadata record of a published item, 
including an author, a link to the item in the context of the 
publisher's site, a publication date, and potentially the content of the 
item.

----------

 From the RevisedConceptualModel article in the Wiki, at 
http://www.intertwingly.net/wiki/pie/RevisedConceptualModel:

"We have a real chance here to make something that is supremely simple, 
totally trend-free, and unquestionably usable. It should be about 
simplicity, ground up design, and precise semantics. If it's not, then 
it'll just continue to be replaced, ever more confusingly, for users.

For example, an entry/article/document can be published many times in 
many locations, can be updated, and can go through numerous other 
processes. If entries became a much more general thing, independent of 
when they were published, that would be a helpful level of generalization. "

----------

 From the WhatIsAnEntry article (to which you yourself contributed), at 
http://www.intertwingly.net/wiki/pie/WhatIsAnEntry:

resource
     Definition: A resource can be anything that has identity. Familiar 
examples include an electronic document, an image, a service (e.g., 
"today's weather report for Los Angeles"), and a collection of other 
resources. Not all resources are network "retrievable"; e.g., human 
beings, corporations, and bound books in a library can also be 
considered resources. [WWW]RFC2396

feed, channel:
     Definition: A collection of resources updated day-to-day and 
appearing in chronological order.

entry, record
     Definition: An entry or record is some structured metadata about a 
resource, comprising one or more attributes and their associated values.

----------

My point is that this is exactly the sort of thing that the feed data 
model was originally intended to represent. The same is, of course, true 
for syndication, which is itself not much more than a specialized kind 
of introspection. If anything we should be doing "Introspection-based 
syndication", but it's too late for that; syndication is already 
defined, and introspection is not. We can, however, correct that error 
by using feed-based introspection; we are still early enough in this 
standard's specification that which one came first -syndication versus 
introspection- need not make much of a difference. But if we are going 
to correct this problem, we need to do it here and now, before we make 
the problem any worse.

- Beecher Greenman