Subject: Posted PaceCategoryElement

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 11:28:18 -0800

Somehow, we don't seem to have any category element in the 
format-draft.  Huh?  It's in RSS2 and it's widely deployed, although it 
hasn't been all that useful.  Also I note that the protocol design team 
is worrying about querying and defining categories.  I don't see 
anything wrong with RSS2's category element, so I've proposed something 
along the same lines:  
http://www.intertwingly.net/wiki/pie/PaceCategoryElement  -Tim

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 8 Nov 2004 14:59:00 -0500

> http://www.intertwingly.net/wiki/pie/PaceCategoryElement  -Tim

Looks good.

I think allowing multiple atom:category elements
*and* allowing the textual content of the element to be a "/" separated 
multi-part string is a bit too much. I think we should pick one or the 
other mechanism, not both. 

If we do go with a separated list, I would prefer a white space separated list
as opposed to "/". I will point to the HTML link elements @rel
attribute as prior art.

What value of @domain should be used if a pre-existing classification
scheme is not used?

Should we mimic the dublin core definition of 'subject' which says:
   "Recommended best practice is to select a value from 
    a controlled vocabulary or formal classification scheme." 

    Thanks,
    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: David Czarnecki <[email-masked]>
Date: Mon, 8 Nov 2004 15:18:19 -0500

> other mechanism, not both. 

I read the textual content part as that would be the specific category an item
was posted to, not that the / would separate the categories. Example:

<category>/music/NIN/</category>

Meaning this item was posted into the specific NIN category.

Is this your thinking Tim?

> as opposed to "/". I will point to the HTML link elements @rel

What about the following?

<category>Nine Inch Nails</category> 

You'd want, <category>Nine+Inch+Nails</category>?

> What value of @domain should be used if a pre-existing classification

Should this be an optional attribute as with RSS 2.0?

---

From: Antone Roundy <[email-masked]>
Date: Mon, 8 Nov 2004 13:57:21 -0700

On Monday, November 8, 2004, at 01:18  PM, David Czarnecki wrote:
>> If we do go with a separated list, I would prefer a white space 
>> separated
>> list

-1 to multiple categories in one <atom:category />.
+1 to multiple <atom:category />s.
-1 to any MUSTs for how categories are to be expressed 
("slash-separated hierarchical"...).
-0.9 to any SHOULDs on how categories are to be expressed.
+0.1 to @domain being optional.

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 8 Nov 2004 13:02:26 -0800 (PST)

--- Tim Bray <[email-masked]> wrote:
> hasn't been all that useful.
 
> I don't see 

It hasn't been all that useful yet you want to propose
it is added to Atom? 

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #222
I reserve the right to execute any henchmen who appear to be a little too intelligent, powerful, or devious. However if I do so, I will not at some subsequent point shout "Why am I surrounded by these incompetent fools?!"

__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com

---

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 13:03:49 -0800

> other mechanism, not both.

Consider the categories in 
http://www.tbray.org/ongoing/When/200x/2004/11/06/WearingFast - I think 
it has two categories, each of which has a /-separated "pathname".

> separated list

Hmm, I don't care that much about the syntax, but check my example 
again, some of the category names have white space in them.

> What value of @domain should be used if a pre-existing classification

domain= is not required.  In my own case, I'd make up a value in 
www.tbray.org/ongoing/

>     a controlled vocabulary or formal classification scheme."

I can go for that. -Tim

---

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 13:06:53 -0800

> It hasn't been all that useful yet you want to propose

It's widely-deployed in practice, it's cheap & easy to generate, it's 
easy to ignore, and who knows, maybe something good will start falling 
out. -Tim

---

From: Sascha Carlin <[email-masked]>
Date: Mon, 08 Nov 2004 22:14:39 +0100

+1 for (multiple) <atom:category />s

-1 for domains if req, +1 if optional

For instance we could then define a domain pointing to del.ico.us and 
use this category list to categorize our items. Or we could point to our 
own categorization scheme and use our own categories.
The document behind the URI could be human legible, providing 
information about the categories.

Just my fast first 2 cents ;)

--
Sascha Carlin
website: http://www.itst.org/
blog:    http://www.itst.org/web/
mailto:  [email-masked]
icq:     99327847
skype:   saschacarlin
mobile:  +49 177 3074952
gpg:     http://www.itst.org/sc_at_itst_dot_net.asc

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 8 Nov 2004 16:23:20 -0500

> it has two categories, each of which has a /-separated "pathname".

Ok, so the / separates path elements and not new keywords/subjects.
That works for me. (Maybe incude more verbage or an example of 
this in the Pace?)

> again, some of the category names have white space in them.

Since I misunderstood the use of the '/' just ignore what I said
about preferring a space.

    Thanks,
    -joe

---

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 13:54:17 -0800

Good enough.  Initial feedback is:

- need better explanation on use of slashes
- @domain needs to be optional

  -Tim

---

From: Graham <[email-masked]>
Date: Mon, 8 Nov 2004 21:56:04 +0000

On 8 Nov 2004, at 7:28 pm, Tim Bray wrote:

> format-draft.  Huh?  It's in RSS2 and it's widely deployed, although 
> it hasn't been all that useful.  Also I note that the protocol design 
> team is worrying about querying and defining categories.  I don't see 
> anything wrong with RSS2's category element, so I've proposed 
> something along the same lines:  
> http://www.intertwingly.net/wiki/pie/PaceCategoryElement

I think a single plain text non-hierachical, no domain nonsense element 
is all that needs to be in the core.

Slightly OT, but why did you bother to define a category construct if 
you're only using it once? It's not good for readability (but then 
neither is any part of our current template).

Graham

---

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 13:56:00 -0800

> -0.9 to any SHOULDs on how categories are to be expressed.

I think the this/that/the-other usage is well-enough established now to 
qualify as prior art.  Anyhow, if you want to have your own 
not-hierarchical categorization scheme, you can, just keep it in your 
own namespace.  You can even put it inside atom:category.  -Tim

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 08 Nov 2004 21:57:04 +0000

> http://www.intertwingly.net/wiki/pie/PaceCategoryElement  -Tim

Good idea, -1 on the details.

If there can be zero or more, The categories should be placed in an 
atom:categories block (we made this mistake before with entries and 
solved in inversely via the atom:head element). The idea of a path 
based syntax is overconstraining. The @domain attribute is redundant 
  - let people use URIs if they want to use URIs. Feed level 
catgeories are dubious if only because a whole side-thread will 
start on catgegory defaulting.

This would be enough:

atom:entry
  - atom:categories?
      - atom:category +

cheers
Bill

---

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 14:04:20 -0800

On Nov 8, 2004, at 1:56 PM, Graham wrote:

> you're only using it once? It's not good for readability

Twice.  Once in feed and once in entry.  There are a lot of 
"Constructs" defined for precisely this reason, i.e. two usages.  If a 
lot of people agree with Graham that this is awkward, I'm sure our 
editors would be happy to address it.  You could replicate it or, for 
the occurrence in atom:head you could say 'For details, see the 
description in "atom:entry"'.  I think the latter would be an 
improvement, but I don't think it's a big deal. -Tim

---

From: Danny Ayers <[email-masked]>
Date: Mon, 8 Nov 2004 23:13:38 +0100

I think a category element could be useful, but I have a few questions first:

> It's widely-deployed in practice,

Where? 
Any examples of its use by producers? 
Any examples of its use by consumers? 

What categorization schemes are in use with RSS 2.0? 

Are all common categorization schemes compatible with the provided
structure? (hierarchy, tagging etc)

Are all common categorization schemes compatible with the slash delimiter?
What is the significance of the order of the keywords (if any)?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 14:23:24 -0800

On Nov 8, 2004, at 1:57 PM, Bill de hÓra wrote:

> solved in inversely via the atom:head element).

Why?  It's clearly a good idea to separate the header material and the 
entries because some of the header material applies to the entries.  
It's not obvious to me what the benefit is from pouring the categories 
into a block.  I'm not against it, just having trouble seeing where it 
would help.

>  The idea of a path based syntax is overconstraining.

Well, there's a lot of prior art there, and for the default text, it's 
handy to have some shared understanding of structure.  If you want to 
use your own non-hierarchical category text, you can, just put it in a 
different namespace.  Hmm... would you be happier with something like 
this?

<cats>
   <cat>this/that/the other</cat>
   <cat>foo/bar/baz</cat>
   <otherNS:subject>funky non-hierarchical categorization 
info</otherNS:subject>
</cats>

>  The @domain attribute is redundant  - let people use URIs if they 
> want to use URIs.

Once again, just grabbing prior art from RSS2.  Why change things 
without a good reason?

> Feed level catgeories are dubious if only because a whole side-thread 
> will start on catgegory defaulting.

Hmm... except for, people do cat-specific feeds.  If others are against 
them, I'm not going to make a big fuss. -Tim

---

From: Graham <[email-masked]>
Date: Mon, 8 Nov 2004 22:19:33 +0000

On 8 Nov 2004, at 10:04 pm, Tim Bray wrote:

> improvement, but I don't think it's a big deal.

Introducing new terminology that everyone has to look up elsewhere in 
the document should be a last resort. If it's because we're defining 
head and entry separately then maybe we should notice they're 90% the 
same and do something about it.

Graham

---

From: Danny Ayers <[email-masked]>
Date: Mon, 8 Nov 2004 23:42:56 +0100

On Mon, 08 Nov 2004 14:23:24 -0800, Tim Bray <[email-masked]> wrote:

> Once again, just grabbing prior art from RSS2.  

Could you please give some pointers to examples of this prior art.
What categorization schemes are supported?

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Tim Bray <[email-masked]>
Date: Mon, 08 Nov 2004 14:48:48 -0800

>> It's widely-deployed in practice,

Well, it turns out, hardly at all.  I just went through a selection of 
a couple of dozen feeds selected from those I subscribe to, including 
representatives of several major blogging engines, RSS 0.9/1.0/2.0, 
also some big commercial publishers like the NYT and BBC.

My findings:
- more than half have no category information at all
- of those that do, almost all are using dc:subject
- I saw exactly *one* instance of RSS's <category> element, in feeds 
produced by Roller

So... options are:

1. put in category somewhat as I proposed it, on the grounds that it's 
been specified before and it's fairly clean
2. don't put in category, on the grounds that it's not been deployed
3. don't put in category but recommend the use of dc:subject

Opinions?  -Tim

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 8 Nov 2004 14:52:43 -0800 (PST)

--- Tim Bray <[email-masked]> wrote:
> handy to have some shared understanding of
> structure. 

What prior art? I've seen some stuff in Dave Winer's
blog and that's about it. I'm subscribed to 154 feeds
in RSS Bandit of which about 45 use the category
element. Of these only 2 use some sort of hierarchy
based on paths (Dave Winer & Gordon Weakliem) but even
then they aren't even using the same syntax. 

=====

---

From: Sascha Carlin <[email-masked]>
Date: Mon, 08 Nov 2004 23:52:27 +0100

> [...]

++1, so to say ;)

mailto:  [email-masked]>

---

From: Bill de hÓra <[email-masked]>
Date: Mon, 08 Nov 2004 22:54:18 +0000

> into a block.  I'm not against it, just having trouble seeing where it 

The category items belong together thematically. Given entry 
children are unordered I'd rather not see them peppered between 
other elements. I claim keeping the markup tidy is important enough 
to justify the parent.

> Well, there's a lot of prior art there, and [...] 

I'd say link to the prior art in the pace.

> different namespace.  Hmm... would you be happier with something like this?
> 
> <cats>

I hadn't considered it; can't say if anyone else needs it.

> Once again, just grabbing prior art from RSS2.  Why change things 

It's a {uri}name thingy. Do we really need another one of those?

> Hmm... except for, people do cat-specific feeds. 

That's true; but as an implementor I don't know how to tell such a 
feed from another.

cheers
Bill

---

From: Sascha Carlin <[email-masked]>
Date: Tue, 09 Nov 2004 00:08:46 +0100

> 3. don't put in category but recommend the use of dc:subject

Time and again, the discussion whether or not to put something in Atom core.

As web applications evolve over time, so does the usage of meta data.
Therefore I am +1 to incorporating a means to categorize items.

Slow but steady we should go away from saying/thinking 'hey, this is
done in X, so we just use this.' On the long run it will pay back
because of consistency and tightness, if this is the correct English term...

cu, Sascha

---

From: Antone Roundy <[email-masked]>
Date: Mon, 8 Nov 2004 16:29:18 -0700

On Monday, November 8, 2004, at 02:56  PM, Tim Bray wrote:
> I think the this/that/the-other usage is well-enough established now 
> to qualify as prior art.  Anyhow, if you want to have your own 
How about if @domain is omitted, then categories should be 
slash-separated...but if @domain is specified, then use that domain's 
way of indicating categories?

---

From: Robert Sayre <[email-masked]>
Date: Mon, 08 Nov 2004 18:34:52 -0500

> same and do something about it.

You could even say that the way to leave comments on an entry would be 
to include atom:post...

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 00:42:14 +0100

> - I saw exactly *one* instance of RSS's <category> element, in feeds

Thanks, I was wondering.

> 3. don't put in category but recommend the use of dc:subject

Of these options I'd lean closest to 1. but advocate a little further
exploration of what's needed. I like the idea, and <category> seems a
reasonable name.

I'd express the requirements as follows : whatever syntax is used it
should include at least a URI for the scheme, a place for an
identifier of the category within that scheme and a string for a
human-readable label. It should be optional. It should be possible to
use it at either feed or entry level.

As you say, dc:subject is in use (which discounts 2.), but I also
think this is something people would use more if it was reasonably
well worked-out and standardised.

I don't actually think dc:subject as it is currently used is tightly
constrained enough for what's needed - it trades broad deployment for
precision. Atom's element isn't likely to be used that much outside of
Atom.

I don't think RSS 2.0's approach is actually far off the mark, it is
pretty simple and supplying the URI of the schema in use is a major
plus for using alongside other (meta)data systems. But the slash
syntax seems an awfully clunky approach in a syntax that has pretty
natural support for ordered lists and hierarchies... [someone got
shares in MicroParsers Inc..?]

Putting the old RDF hat on, I reckon the SKOS work [1] will mean it
shouldn't be too difficult to map to other systems/schemes as long as
whatever Atom does is reasonably unambiguous.

fyi, there's some other plain-XML prior art that is been used
pointillistically in syndication at [2] and [3], and I reckon it might
be worth seeing if there are any ideas that can be pinched from XTM
[4].

Cheers,
Danny.

[1] http://www.w3.org/2001/sw/Europe/reports/thes/1.0/guide/
[2] http://matt.blogs.it/specs/ENT/1.0/
[3] http://www.xfml.org/spec/1.0.html
[4] http://www.topicmaps.org/xtm/

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Mon, 08 Nov 2004 20:15:07 -0500

> same and do something about it.

Abstract
----------------------------------------
Recast atom:head as an entry.

Status
----------------------------------------
Open

Author: Robert Sayre

Rationale
----------------------------------------
It was productive to spec atom:feeds and atom:entries entirely 
separately, but now that we've done it, it seems they have a lot in common.

Atom Documents
----------------------------------------
Replace:

"An Atom Feed Document is a representation of an  Atom feed, including 
metadata about the feed, and some or all of the  entries associated with 
it. Its document element is atom:feed."

with

"An Atom Feed Document is a representation of an Atom feed, including an 
entry representing the feed itself, and some or all of the entries it 
contains. Its document element is atom:feed."

4 The "atom:feed" Element
----------------------------------------
Replace

"The 'atom:feed' element is the document (i.e., top-level)  element of 
an Atom Feed Document, acting as a container for  metadata and data 
associated with the feed. Its first element  child MUST be atom:head, 
which MAY be followed zero or more  atom:entry child elements."

with

"The 'atom:feed' element is the document (i.e., top-level) element of an 
Atom Feed Document, acting as a container for entries associated with 
the feed. It MUST contain one atom:headentry element, which MAY be 
followed zero or more  atom:entry child elements."

4.2 The "atom:headentry" Element
----------------------------------------

Replace:

"The atom:head element acts as a container for metadata about the  feed 
itself."

with:

"The 'atom:headentry' is an Atom Entry which provides a representation 
of the feed itself. The only additional restriction placed on atom:entry 
is that it MUST contain an atom:generator element."

----------------------------------------

Remove: 4.2.11 "atom:info" Element

----------------------------------------

Move: 4.2.3 "atom:introspection" Element
to atom:entry

----------------------------------------

Move: 4.2.4 "atom:post" Element
to atom:entry

"The 'atom:post' element is a Service construct that conveys the URI 
used to add entries to a feed which will have the parent entry as its 
headentry. atom:entry elements MUST NOT contain more than  one atom:post 
element."

----------------------------------------

Make atom:tagline a child of atom:feed, which must appear before 
atom:headentry.

----------------------------------------

---

From: Ezra Cooper <[email-masked]>
Date: Mon, 8 Nov 2004 17:46:04 -0800

> own namespace.  You can even put it inside atom:category.  -Tim

FWIW, the protocol design team came out pretty firmly against the idea 
of enforcing a hierarchy on categories 
(categories-as-discoverable-protocol-items, that is). DAGs were thought 
to be a realistic use-case, and maybe other non-hierarchical 
structures, too.

If a category element is needed in the feed format, let's not impose 
any relationships between them. What use could it have? If there are 
existing schemes that are hierarchical, then consumers can make use of 
that meaning.

Imposing semantics on the slash character within the human-readable 
category name could have problems. Consider my (flat) category scheme 
for life:

   Animals
   Plants
   Fungi
   Protozoa/Monera

When it comes to single-celled buggers, I'm not very discriminating.

Ezra

---

From: Robert Sayre <[email-masked]>
Date: Mon, 08 Nov 2004 21:47:14 -0500

Graham wrote:
> On 9 Nov 2004, at 1:15 am, Robert Sayre wrote:
> 
>> Abstract
> No that sucks. Reformat the spec to combine everything, but keep the 
> actual syntax exactly the same as it is now.

No, Graham, it doesn't suck. It's how every other format with a similar 
problem deals with it.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 9 Nov 2004 02:45:04 +0000

Graham

---

From: Robert Sayre <[email-masked]>
Date: Mon, 08 Nov 2004 22:06:19 -0500

> No, Graham, it doesn't suck. It's how every other format with a similar 

You know, after calmly replying, I still can't believe you would write 
something like that. What makes you think it's OK to interact like a 
14yr old who thinks he knows everything? It's days like this when I wish 
email programs would hurry up and add support for feeds, allowing the 
market to consolidate.

Robert Sayre

---

From: Henry Story <[email-masked]>
Date: Tue, 9 Nov 2004 04:16:49 +0100

+1

On this. I was just working on modeling the latest Atom draft in OWL,  
and had come to think this would simplify things quite nicely. I had in  
fact suggested somthing similar in my previous atom-owl model [1].

I will implement your suggestions below in my latest model. They seem  
good to me.

Henry

[1]  
http://bblfish.net/work/atom-owl/2004-08-12/ 
blogexample.html#entry.2004-08-12-2035.n3

On 9 Nov 2004, at 02:15, Robert Sayre wrote:

> metadata about the feed, and some or all of the  entries associated  
> with it. Its document element is atom:feed."
>
> with
>
> an entry representing the feed itself, and some or all of the entries  
> it contains. Its document element is atom:feed."
>
>
>
> an Atom Feed Document, acting as a container for entries associated  
> with the feed. It MUST contain one atom:headentry element, which MAY  
> be followed zero or more  atom:entry child elements."
>
>
>
> "The atom:head element acts as a container for metadata about the   
> feed itself."
>
> with:
>
> of the feed itself. The only additional restriction placed on  
> atom:entry is that it MUST contain an atom:generator element."
>
> headentry. atom:entry elements MUST NOT contain more than  one  
> atom:post element."
>
>

---

From: Dare Obasanjo <[email-masked]>
Date: Mon, 8 Nov 2004 19:35:49 -0800 (PST)

> No, Graham, it doesn't suck. It's how every other

Anyone can pull generalizations out of thin air. Can
you back up this claim with examples of XML formats
that do this? 

It seems pretty kludgy to me but its not like I care
much what elements are called anyway, I'll write that
code once and never think about it again. 

=====

---

From: Robert Sayre <[email-masked]>
Date: Mon, 08 Nov 2004 23:10:08 -0500

> you back up this claim with examples of XML formats

I don't really care to limit the argument to XML formats... I see that 
as orthogonal.

WebDAV
Web Collections
JSR 170
HTML Tables (th and td are cells)

that's off the top of my head. I'm sure I could think of more. It's not 
like it's a super weird solution, and it allows a convenient way to do 
comments and other hierarchies (#1 request that's not on the Pace list).

Maybe one of you should write something if you're so unhappy. This is 
what people who care about an issue do. If you don't care, please don't 
waste everyone's time.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Tue, 9 Nov 2004 04:22:30 +0000

On 9 Nov 2004, at 3:06 am, Robert Sayre wrote:

> 14yr old who thinks he knows everything? It's days like this when I 
> wish email programs would hurry up and add support for feeds, allowing 
> the market to consolidate.

Reading it again, the tone of my reply doesn't really match what I 
meant. Try:

No that [doesn't make much sense to me]. [What we should do is] 
Reformat the spec to combine everything, but keep the actual syntax 
exactly the same as it is now.

I like to leave some things implied, but that often work in email with 
strangers. Sorry if I offended you.

Graham

---

From: Joe Gregorio <[email-masked]>
Date: Mon, 8 Nov 2004 23:39:32 -0500

> Make atom:tagline a child of atom:feed, which must appear before

This is the only part I don't understand. You made atom:generator
a mandatory part of atom:headentry, why not atom:tagline?

    -joe

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 11:42:24 +0100

On Mon, 8 Nov 2004 17:46:04 -0800, Ezra Cooper <[email-masked]> wrote:

> any relationships between them. 

+1.

> When it comes to single-celled buggers, I'm not very discriminating.

That's a little harsh, just 'cause they can't fight back!

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 11:49:12 +0100

+1

My first impressions are positive, this looks pretty elegant, though
of course that's no reliable measure. But I know how much time Henry's
been spending on the OWL-based modelling (in a UMLish style), and if
he reckons it works there then I'd suggest that's pretty strong
validation.

10/10 for the Pace title.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Lance Lavandowska <[email-masked]>
Date: Tue, 9 Nov 2004 09:50:52 -0600

> existing schemes that are hierarchical, then consumers can make use of

I want to make sure I understand the full import of what you are
saying here.  Are you suggesting Atom not define any mechanism for
defining hierarchy and/or other relationships?

One of the earlier proposals (cannot find the Pace now) was for
something along the lines of:

<category>Animals
    <category>Mammals
        <category>Felines</category>
    </category>
</category>

I have the same problems with using the slash character as you, and
this seems a reasonable mechanism for describing hierarchy in ad hoc
systems (if a bit verbose).

Add in @id and I could declare all my categories in the Feed and then
reference them in each entry:

<category refid="foo" /><!-- Felines -->
<category refid="bar" /><!-- Virii -->

Lance Lavandowska

---

From: Lance Lavandowska <[email-masked]>
Date: Tue, 9 Nov 2004 09:55:00 -0600

> a mandatory part of atom:headentry, why not atom:tagline?

Since neither is part of the Entry construct perhaps they both should
be children of atom:feed.

Lance Lavandowska

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 07:54:02 -0800

> Abstract

Rob, could you please publish an example of what a feed would look 
like?  The number of changes overflows my input buffer.

I'm having trouble understanding the angst.  The latest format draft 
has two different elements (feed and entry) which are quite different 
things, but share a number of common child elements.  So why is this a 
problem? -Tim

---

From: Antone Roundy <[email-masked]>
Date: Tue, 9 Nov 2004 09:22:02 -0700

> way of indicating categories?
Okay, I'm slow, but I'm catching the vision of why it would be good to 
have a standard way of recognizing that a category specifier specifies 
not only the end node in the hierarchy, but the path to it.  Perhaps we 
could say that if @domain is not specified, some particular character 
(whether it be / or | or something else) MUST NOT be used except as a 
hierarchical level separator, and if @domain is specified...it SHOULD 
NOT? Or would it be useful to do something like this:

<category domain="foo:bar" 
hierarchy-separator="*">Technology*Computers*Internet</category>

where, if @domain is not specified, @hierarchy-separator defaults to 
"/", and if @domain is specified, @hierarchy-separator defaults to 
undefined.

---

From: Graham <[email-masked]>
Date: Tue, 9 Nov 2004 16:23:42 +0000

> things, but share a number of common child elements.  So why is this a 

Because it isn't readable. No one except a machine is capable of 
reading two wordy near-identical definitions and taking in the subtle 
differences. What we're doing essentially is hiding that information. 
Can't we just tell them how something works in atom:head and in 
atom:entry.

An ideal spec layout would be:

2.1 atom:head
An atom:head element MUST contain the following child elements:
- Exactly 1 atom:title element
- 1 or more atom:link elements
- etc

2.2 atom:entry
ditto

3.1 atom:link
	[general atom:link definition, followed by]
	In atom:head, atom:link must blah, whereas in atom:entry blah blah

3.2 atom:title
	...

3.3 Date Constructs
	[general date construct def]
	3.3.1 atom:updated
	3.3.2 atom:published
etc

There you go. Note I can code a feed generator just by working through 
the list in 2.1 and 2.2.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Tue, 09 Nov 2004 11:47:38 -0500

Tim Bray wrote:

> 
> I disagree with Graham and think that the draft as it stands is 
> acceptably usable.  On the other hand, it might become more so flipped 
> around this way; what do our editors think? 

No opinion, but I'm willing to draft it that way to see which one people 
prefer.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 08:44:59 -0800

Graham's suggesting flipping the draft around to make it read top 
down... i.e. move section 4. atom:feed up to be section 2.

I disagree with Graham and think that the draft as it stands is 
acceptably usable.  On the other hand, it might become more so flipped 
around this way; what do our editors think?  -Tim

> An ideal spec layout would be:

2.0 atom:feed
An atom:feed element MUST contain one atom:head element and zero or 
more atom:entry elements

---

From: Zhang Yining <[email-masked]>
Date: Wed, 10 Nov 2004 02:49:26 +0800

I am not against the hierarchical structure (anyway flat structure is 
hierarchical structure in a special form). However, the question is: How 
and how much would the server side synidcation service (e.g. bloglines, 
MyYahoo!) and the desktop aggregators add value with such hierarchy 
structure information in both feed and entry?

Press further, how do they handle when the feed owner changes the 
hierarchy structure (by renaming/moving/inserting/removing part of the 
parth?)

I strongly suggest that we come out a list of use cases and that would 
make the discussion and decision much easier.

e.g. will the autodiscovery prompts user the available feeds of 
different categories, or allow user choose which categories to subscribe?

Somehow I feel the tags used by flickr and delicious is good enough.

Yining

---

From: Danny Ayers <[email-masked]>
Date: Tue, 9 Nov 2004 21:22:45 +0100

> structure information in both feed and entry?

I would say very little at present.

> hierarchy structure (by renaming/moving/inserting/removing part of the

I think in the context of Atom you'd have to leave that to the
applications at the end of the line. I imagine it should be possible
to use Atom Protocol to maintain and synchronise such structures.

> make the discussion and decision much easier.

I would put forward:  server-side categorization as provided by
blogging tools, where the user either adds arbitrary tags or builds a
tree of labels; bibliographic style categorization, where the entries
are associated with standard categorizations.

> different categories, or allow user choose which categories to subscribe?

That sounds feasible, though probably quite tricky.

> Somehow I feel the tags used by flickr and delicious is good enough.

I believe PaceCategoryRevised will allow simple tagging :

<category term="animals" />

possibly more personal:

<category term="animals" scheme="http://myexampleblog.com" />

as well as more a more standardised approach:

<category term="animals" scheme="http://flickr.com" />

a bit richer:

<category term="Dog-2" scheme="http://xmlns.com/wordnet/1.6/" label="Dog" />

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Tue, 09 Nov 2004 18:09:49 -0500

> like?  The number of changes overflows my input buffer.

There really aren't very many changes. Just removes all the stuff that 
says "feed" instead of "entry" and makes four changes.

I added an example on the wiki:
http://www.intertwingly.net/wiki/pie/PaceEntriesAllTheWayDown

> I'm having trouble understanding the angst.  The latest format draft has 
> two different elements (feed and entry) which are quite different 
> things

The latest format draft defines two document types, feeds and entries. 
With this change, it still does. The difference is that data about the 
feed is stored in an entry instead of a head element.

> but share a number of common child elements.  So why is this a 
> problem?

There's no way to identify data about the feed itself, which is usually 
an output resource (generated in some way). Using this approach, it 
becomes straightforward to address the Feed's attributes using the 
protocol. It makes no difference to a feed consumer (change the element 
name, so what?), though it does add a handy way to do on-demand comments 
and such, as shown in the second example.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 15:43:08 -0800

> says "feed" instead of "entry" and makes four changes.

A change this big, this late in the process, makes me nervous.  There 
are other ways to shorten the spec (we were discussing some today).  
What makes me nervous is we're asserting that a <head> and an <entry> 
are the same, except that <head> has to have a generator... it smells 
like, when I'm building some software, and I catch myself thinking 
"gee, this thing and that thing are almost the same thing" and I try to 
unify them and find extra arguments and variables creeping into methods 
to make up for the fact that they're not *quite* the same.  It seems to 
me that <head> and <entry> are two different bundles of metadata, in 
which a lot of the same elements can appear.

But if the WG is massively in favor of the change, I'm OK with it.

Finally, <headentry> is a bogus element name.  Either it's a <head> or 
it's an <entry class="head">.  -Tim

---

From: Robert Sayre <[email-masked]>
Date: Tue, 09 Nov 2004 19:15:10 -0500

Tim Bray wrote:
> A change this big, this late in the process, makes me nervous.  

Let's see. The atom:head element appeared rather recently, and the 
format isn't supposed to go to Last Call until March, 2005.

> There 
> like, when I'm building some software, and I catch myself thinking "gee, 
> this thing and that thing are almost the same thing" and I try to unify 
> them and find extra arguments and variables creeping into methods to 
> make up for the fact that they're not *quite* the same.  It seems to me 
> that <head> and <entry> are two different bundles of metadata, in which 
> a lot of the same elements can appear.

Well, I see your point, except that the protocol currently requires a 
generator element to appear in an Entry Document (not reflected in the 
format spec), so maybe the elements in the feed are the exception. [0]

 > it's an <entry class="head">.

It's a <head>, then.

Robert Sayre

[0] 
http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-02.html#rfc.section.3.6.11

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 9 Nov 2004 20:07:17 -0500

Robert Sayre wrote:
> Tim Bray wrote: ...
>> Either it's a <head> or it's an <entry class="head">.
> It's a <head>, then.
	If <head/> is an entry, can an entry contain an entry? We really
need PaceHeadInEntry to make aggregated feeds work. 

		bob wyman

---

From: Antone Roundy <[email-masked]>
Date: Tue, 9 Nov 2004 18:14:35 -0700

I am really not getting this.

On Tuesday, November 9, 2004, at 04:09  PM, Robert Sayre wrote:
> There's no way to identify data about the feed itself
Huh?  Isn't the stuff in atom:head data about the feed?

> which is usually an output resource (generated in some way).
...?

[snip]

> though it does add a handy way to do on-demand comments and such, as 
> shown in the second example.
Let me see if I'm understand this correctly: The first example shows a 
"normal feed".  The <entry>'s <post> is the URI to post comments on 
that entry to. The second example is the feed created when someone 
posts a comment to that URI. Okay, I finally get that much (I think the 
explanation could be more clear--I may post a suggestion later).

Question: what is the URI from which one is to fetch the comment feed?  
How does one find that?

On Tuesday, November 9, 2004, at 04:43  PM, Tim Bray wrote:
> "gee, this thing and that thing are almost the same thing" and I try 
> to unify them and find extra arguments and variables creeping into 
> methods to make up for the fact that they're not *quite* the same.  It 
> seems to me that <head> and <entry> are two different bundles of 
> metadata, in which a lot of the same elements can appear.
Yeah, that's my take on it too.  I don't see enough benefit coming out 
of this to justify the change.  Separating things in the spec, even if 
it results in duplication, seems more clear.  If only an element or two 
was different, that would be one thing, but it seems to me that the 
differences run much deeper.

---

From: Tim Bray <[email-masked]>
Date: Tue, 09 Nov 2004 17:23:16 -0800

> need PaceHeadInEntry to make aggregated feeds work.

Why can't an <entry> contain a <head> that's also sorta-kinda an entry? 
  As long as we agree that a <head> can't contain a <head> or an 
<entry>, there's no confusion.

Assuming of course that the WG wants to agree on HeadInEntry; I don't 
know enough about aggregators to have a useful opinion pro or contra.  
Bob, if we take HeadInEntry, should we lose atom:origin?  -Tim

---

From: Graham <[email-masked]>
Date: Wed, 10 Nov 2004 01:19:26 +0000

On 9 Nov 2004, at 11:43 pm, Tim Bray wrote:

> It seems to me that <head> and <entry> are two different bundles of 

Yes. The thing they have in common is that they are both Atom container 
elements. Other than that they're completely different. An atom:entry 
can inherit values (Author etc) from atom:head. I don't think one thing 
can inherit values from another thing that is conceptually its sibling.

Graham

---

From: Graham <[email-masked]>
Date: Wed, 10 Nov 2004 01:36:41 +0000

On 10 Nov 2004, at 1:23 am, Tim Bray wrote:

> I don't know enough about aggregators to have a useful opinion pro or 
> contra.

The Pace makes no mention of how the data inside the head-in-entries  
is to be processed, which says to be it hasn't been thought through. I 
presume it would supercede the feed's main atom:head, in which case the 
head-in-entry should really be the first element, for the same reason 
the main atom:head is first.

Graham

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 9 Nov 2004 21:05:08 -0500

> Bob, if we take HeadInEntry, should we lose atom:origin?  -Tim
	If PaceHeadInEntry is accepted, then you don't need atom:origin
since atom:id is an element of atom:head. If atom:head can be a child of
atom:entry, then you don't need to fabricate atom:origin as a means of
copying the feed's atom:id into the entry.

		bob wyman

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 9 Nov 2004 21:35:06 -0500

Graham wrote:
> I presume [the head-in-entry] would supercede the feed's main atom:head
	No. The atom.entry.head conveys completely different information
then atom.feed.head. One should not supercede the other. Each has a role and
each can be useful simultaneously.
	For instance, I might produce the following feed:
<feed>
  <head><copyright>Second Feed Corp.</copyright></head>
  <entry>
    <head><copyright>Source Feed Inc.</copyright></head>
	<copyright>Tom Bombadil</copyright>
      ...
  </entry>
</feed>
	The copyright for this feed, as a collection, is claimed by "Second
Feed Corp." but the feed contains an entry whose copyright was claimed by
"Tom Bombadil". Tom's entry had been extracted from a feed whose copyright
was claimed by "Source Feed Inc.". All three copyright claims are active,
valid, and "interesting" in at least some contexts.

> The Pace makes no mention of how the data inside the 
> head-in-entries is to be processed, which says to be it 
> hasn't been thought through.
	I'm sure you won't be surprised to read that I actually do think
that I've thought this through... But, that clearly isn't being
communicated. I'd appreciate it very much if you could provide some specific
questions that you think need to be answered. My fear is that if I write
more, I will have written too much.

		bob wyman

---

From: Antone Roundy <[email-masked]>
Date: Tue, 9 Nov 2004 19:59:05 -0700

> valid, and "interesting" in at least some contexts.
But what about this:

<feed>
	<head><author><name>Joe</name></author></head>
	<entry>
		<head><author><name>Moe</name></author></head>
		...<!--various stuff NOT including an author element-->...
	</entry>
</feed>

According to the current draft (or at least the implication of <head> 
requiring an <author> unless every <entry> has one), <entry> inherits 
<author> from <feed>.  The the example above, it would make more sense 
for the entry's author to be Moe than Joe--Moe was the author when the 
entry was in its original feed, and aggregating into into this feed 
shouldn't change that.

At a glance, it looks like <copyright> is the only other element that 
might get inherited by <entry>:

    "The atom:copyright element may be assumed to apply to all entries
    contained by the feed except those entries which contain
    atom:copyright elements.  The atom:copyright element MUST, if
    present, be considered to apply to the feed as a collection of
    entries."

and later:

    "If an atom:entry element does not contain an atom:copyright element,
    then the atom:copyright element of the containing atom:feed element's
    atom:head element, if present, should be considered to apply to the
    entry."

In that case too, clearly the copyright on the entry is not going to 
change just because it got aggregated into another feed.

---

From: Eric Scheid <[email-masked]>
Date: Wed, 10 Nov 2004 14:24:19 +1100

On 10/11/04 10:43 AM, "Tim Bray" <[email-masked]> wrote:

> It seems to 

and remember that the reason many of the <entry> elements which appear in
<head> is just as a shorthand means of eliminating duplication in every
<entry>. Remove those from <head> and you've got much less overlap, right?

e.

---

From: "Bob Wyman" <[email-masked]>
Date: Tue, 9 Nov 2004 23:33:22 -0500

Antone Roundy wrote:
> According to the current draft (or at least the implication of
> <head> requiring an <author> unless every <entry> has one), 
> <entry> inherits <author> from <feed>.  The the example above, it
> would make more sense for the entry's author to be Moe than Joe
>--Moe was the author when the entry was in its original feed, and
> aggregating into this feed shouldn't change that.
	You are correct. And, if we ever get to the point of actually trying
to replace the "[[explain inheritance]]" placeholder in the draft with real
language then we'll be able to work these issues out.
	Basically, my position will be that an entry should ONLY inherit
from the feed.head of that entry's source feed. If an entry is in a
"foreign" feed, the feed metadata should be understood to apply to the feed
as a container -- not to any externally sourced entries. Thus,
feed.head.copyright feed.head.author, etc. specify attributes of the feed as
a collection and are only inherited by "native" entries that do not
explicitly provide this data.  
	The easiest way to specify this is to say:
	1. Feed metadata is only inherited by entries that do not contain a
head element. Or, you only inherit from the "closest" head element.
	2. Entries imported into a feed must contain a head element whose
content should be the feed.head of their source.
	I think this is a very simple set of rules...

>		...<!--various stuff NOT including an author element-->...
	It is clear that the author of the entry is Moe, not Joe. The reason
is that the entry contains a head. Thus, the feed's head can't be used for
inheritance.
	By declaring the two simple rules above, we also provide a mechanism
for defining and controlling the "paths of inheritance" for any extension
elements, attributes, etc. which might be defined in the future. This is a
good thing since it means that we can expect more consistent implementation
of inheritance across the board and thus a greatly likelihood of
interoperability.
	Note: I would argue that the two rules above should be specified in
a general statement about inheritance. I don't think it would be a good idea
to write them into the description of each inheritable element. Thus, I
wouldn't put those rules in either atom:copyright or atom:author. The rules
should stand on their own or be written into the definition of <head/>.

		bob wyman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Antone Roundy
Sent: Tuesday, November 09, 2004 9:59 PM
To: [email-masked]
Subject: Re: PaceEntriesAllTheWayDown

But what about this:

<feed>

and later:

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 13 Nov 2004 02:09:53 +0100

> http://www.intertwingly.net/wiki/pie/PaceCategoryElement

I like PaceCategoryRevised a couple of notches better, so I'd say I'm +0.5  
on PaceCategoryElement.

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

---

From: Tim Bray <[email-masked]>
Date: Fri, 12 Nov 2004 17:26:16 -0800

On Nov 12, 2004, at 5:09 PM, Asbjørn Ulsberg wrote:
> I like PaceCategoryRevised a couple of notches better, so I'd say I'm 
> +0.5 on PaceCategoryElement.

Me too.  I'm going to mark PaceCategoryElement withdrawn. -Tim

---

From: Henry Story <[email-masked]>
Date: Sat, 13 Nov 2004 10:29:22 +0100

Reading this thread really quickly I noticed that there are a few 
overlapping problems
that are tending to make the thinking about this a little more 
complicated that necessary:
	- do the feed head and entry elements resemble themselves enough?
	- is a Feed an Entry?
	- is a Feed a sequence of Entries with the head element being special?
	- how does making changes affect the already dodgy inheritance problem?
	- Bob Wyman's proposals about needing to keep the whole metadata of a 
feed for an
	Entry.

If the feed head elements can really be seen to be the same as an Entry 
element, I am all for the simplification. There are then a couple of 
ways to model this: Feed is a Entry or Feed is a sequence of Entries.

The "inheritance" problem should take second place to any of the obove 
issues. I also need to spend more time really understanding Bob Wyman's 
point to see how that affects the problem or if there are other 
solutions to it.

But I have to leave,

Henry Story

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 13 Nov 2004 15:21:07 +0000

> Me too.  I'm going to mark PaceCategoryElement withdrawn. -Tim

I'm warm on it; two things.

1. The current text implies you should use taxonomies. I suggest 
this alternate text, which implies you can and here's how.

"""
The atom:category element contains information about a category to 
which an Atom feed or entry is associated.  It has one attribute, 
"domain", which is a URI that identifies a categorization scheme. 
Its textual content SHOULD be a string. Where taxonomic categories 
are used, their parts MUST separated by a forward slash ("/") character.
"""

2. My reading is that the presence of @domain is a MUST. I would 
prefer it to be a MAY. Not all categories need have URIs.

cheers
Bill

---

From: "Bob Wyman" <[email-masked]>
Date: Sat, 13 Nov 2004 12:02:00 -0500

Henry Story wrote:
> I also need to spend more time really understanding Bob Wyman's 
	Perhaps this might make it easier:
	Imagine that there are two feeds that you wish to read: A and B.
	Now, imagine that you have two choices for how to read the content
of these two feeds:

	1. Receive each feed individually
	2. Or, Receive both feeds in a composite feed

	I argue that your choice should make no difference. There should be
no information loss as a result of passing entries through a composite feed.
In fact, if all of the entries of a source feed are passed through a
composite feed, you should be able to faithfully reconstruct the original
source feed. (You might think of the composite feed creation process as one
of "tangling" multiple feeds. Then, you should be able to "untangle" them.)
	Since it is clear that at least some feed-level metadata is part of
the information associated with an entry, I contend that when we remove
entries from their source feeds, we should copy that meta-data as well. The
feed-level metadata is just as much a part of an entry as are the children
elements of the <entry/> element.

		bob wyman

---

From: Tim Bray <[email-masked]>
Date: Sat, 13 Nov 2004 09:48:16 -0800

> complicated that necessary:

I am increasingly tending to -1 on EntriesAllTheWayDown, the 
"simplification" it introduces feels strained and spurious.  It is 
natural for a feed to consist of a header and some entries.  Yes, they 
share some fields.  Trying to pretend that the header is an entry 
doesn't really seem helpful. -Tim

---

From: Henry Story <[email-masked]>
Date: Sun, 14 Nov 2004 12:47:32 +0100

On 13 Nov 2004, at 18:48, Tim Bray wrote:

>> overlapping problems that are tending to make the thinking about this 
>> a little more complicated that necessary:
>
> share some fields.

I think Robert Sayre's proposal shows that they don't just share a few 
fields, but that they share quasi all fields.  That is really all that 
we need to show that we are in fact speaking about the same concepts.

It may seem odd to people who have been in this field for a really long 
time, to be told that two things they thought were distinct are really 
the same. But that is where one needs a little flexibility of mind.

Not only is it not "strained and spurious", this simplification is 
natural and obvious. When James Gosling wrote BlogEd he made the head 
an entry. I think this is a simplification that will feel completely 
natural to any OO (or other) software engineer. You have two things 
with a one to one mapping between their field types: immediately look 
to see if there is a similarity.

This would fall under Martin Fowler's "Extract Superclass" Refactoring 
pattern (p336):
	
	Duplicate code is one of the principal bad things in systems. If you 
say things
	in multiple places, then when it comes time to change what you say, 
you have more
	things to change than you should.
	One form of duplicate code is two classes that do similar things in 
the same way
	or similar things in different ways. Objects provide a build-in 
mechanism to
	simplify this situation with inheritance. However, you often don't 
notice the
	commonalities until you have created some classes, in which case you 
need to create
	the inheritance structure later.
	
In our case we have the limit case of this refactoring, in which after 
the extraction
of the commonalities of head and entry, nothing more is left. Ie we 
have simplified our
code from two classes down to one.

The same is clearly true in writing specifications.

>  Trying to pretend that the header is an entry doesn't really seem 
> helpful. -Tim

I think this is so clearly helpful in the clarity of the spec, I find 
it difficult to see how this is not evident. Line number count would be 
a simple objective measurement of this.

When I wrote:

> I noticed that there are a few overlapping problems
> 	1- do the feed head and entry elements resemble themselves enough?
> 	2- is a Feed an Entry?
> 	3- is a Feed a sequence of Entries with the head element being 
> special?
> 	4- how does making changes affect the already dodgy inheritance 
> problem?
> 	5- Bob Wyman's proposals about needing to keep the whole metadata of 
> a feed for an
> 	Entry.

I meant that 1 is clearly to be answered in the positive. The other 
questions need not be affected by refactoring the head as an Entry. 
They are different questions. Treating them all together confuses the 
issue. Let's look at them one by one seperately.

Henry Story

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 14 Nov 2004 12:18:48 +0000

Henry Story wrote:
> natural and obvious. When James Gosling wrote BlogEd he made the head an 
> entry. I think this is a simplification that will feel completely 
> natural to any OO (or other) software engineer. You have two things with 
> a one to one mapping between their field types: immediately look to see 
> if there is a similarity.
> 
> pattern (p336): [...]

I've seen Fowler give advice contra that variant of DRY - where the two 
pieces of code are structurally similar but conceptually different. I 
happen to agree with that advice. Few things are worse in OO systems 
that superclasses whose children are not specializations of it or whose 
children end up being disjoint. IOW I think this smacks of inheritance 
for reuse; and that is an antipattern.

> I think this is so clearly helpful in the clarity of the spec, I find it 
> difficult to see how this is not evident. Line number count would be a 
> simple objective measurement of this.

The similarity between feeds and entries is that they both are metadata 
about web resources. That does not by itself make them conceptually 
similar in the Atom domain. My opinion of the Feed isa Entry approach is 
that it's looking for a abstraction that will serve only to obfuscates 
matters. My experience is that eliding aspects of domain models in 
favour of generic structures is often a flawed approach.

cheers
Bill

---

From: Henry Story <[email-masked]>
Date: Sun, 14 Nov 2004 14:49:52 +0100

On 14 Nov 2004, at 13:18, Bill de hÓra wrote:
>
> The similarity between feeds and entries is that they both are 
> metadata about web resources. That does not by itself make them 
> conceptually similar in the Atom domain. My opinion of the Feed isa 
> Entry approach is that it's looking for a abstraction that will serve 
> only to obfuscates matters.

Bill, I agree in so far as I think that the feed is a Entry issue is a 
separate one from the PaceEntriesAllTheWayDown one.

The simplification given by PaceEntriesAllTheWayDown works just as well 
with the Feed is a Entry model, as with the Feed is a set of Entries 
model [1]. In fact both models could work with current spec text.

When Robert writes the EntriesAllTheWayDown pace "allows a 
straightforward way to implement hierarchy",  I think the word "allows" 
should be understood as saying that  it makes it easier to see that 
this could be done, but not necessarily that is should be done. I think 
that is a separate issue.

What we should first do, is concentrate on the refactoring proposed by 
Robert. As a re-factoring it hardly changes anything at all. But it 
simplifies the spec a lot.

You can accept the refactoring without accepting that a Feed is a 
Entry. You would prefer the model perhaps in which a feed is a set of 
entries, with a special entry being the head entry of the feed. That is 
the model I adopted in my latest attempts at modeling Atom in OWL.

>  My experience is that eliding aspects of domain models in favour of 
> generic structures is often a flawed approach.

"often", but not always. Perhaps you can reference exactly where Martin 
Fowler specifies one should be careful.

Here we still have two classes: a Feed and a Entry class. So we are not 
much more generic than we were beforehand. You could  say that we have 
simplified the Feed class down to its core. In doing so the 
specification has been much clarified.

There is another nice advantage of this on the API side of things. If 
the head of a feed is an Entry then the API might also be simplified 
quite dramatically, since adding all the head information to a feed 
would be just creating a new Entry element and associating it with a 
feed.

> Bill

[1] which I described in my mail
http://www.imc.org/atom-syntax/mail-archive/msg11311.html

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 14 Nov 2004 14:41:10 +0000

Henry Story wrote:

> You can accept the refactoring without accepting that a Feed is a Entry. 
> You would prefer the model perhaps in which a feed is a set of entries, 
> with a special entry being the head entry of the feed. That is the model 
> I adopted in my latest attempts at modeling Atom in OWL.

Not quite. I still don't see that either is a special case of the other. 
I think the data structure for this is a 2-tuple feed(head, list), not a 
1-tuple feed(list) of uniform type. In my mind, the second member of 
that tuple is a delayed list (i.e., a stream [1]), not a set. But of 
course you could represent all the entries as a set, but that's a math 
thing rather than a programming thing.

I recall Bob Wyman's analogy to a sliding window or some such capturing 
my sense of a feed's entries perfectly.

> Fowler specifies one should be careful.

[I'd like to but it I'm pretty sure it was in a yahoo group (I think it 
was extremeprogramming) which are basically unsearchable in reasonable 
time. All I'll say is I'm not making it up - there were two code blocks 
that were doing essentially the same programmatic operation; the 
deciding argument was to leave them as they were since the blocks 
differed in intent at the application level. I remember because it 
surprised me. Inheritance as reuse is (now) a well-understood phenomenon 
in OO.]

> would be just creating a new Entry element and associating it with a feed.

See the data structures comment above. We need to be careful because 
"head" is being used in two distinct senses - one as the name of 
metadata structure that describes the feed; two as the first child of 
the Atom feed element and thus item(0) in any XML/Info set based process).

For 1) the head of a feed is not an entry, it is the first member of 
that 2-tuple. For 2)  the head of the entries is not the head but the 
next entry on the stream; the stream is the second member of the 
2-tuple. That the head looks like the the head of a list of entries is a 
feature both of the XML snapshot you've been given and the vagaries of 
English ;)

Put it this way. my objections to treating the atom:head data structure 
as a kind of atom:entry stands. Otherwise where you and Robert and going 
is interesting.

On further reflection - atom:head might be a confusing name, atom:header 
or atom:about might be better. No big deal, just an ob.

cheers
Bill

[1] http://mitpress.mit.edu/sicp/full-text/sicp/book/node70.html

---

From: Eric Scheid <[email-masked]>
Date: Mon, 15 Nov 2004 02:51:29 +1100

> 2. Or, Receive both feeds in a composite feed

imagine an author writes an entry, and then publishes it...

1. in his main feed
2. in a category-specific feed
3. in some planet-x feed
4. in an RSS 1.0 feed for backwards compatibility

is that the same entry occurring in four different places, or is it four
different entries? My sense is that it is the same entry.

If that entry is then aggregated into a composite feed, does it matter which
feed it originally came from?

The essential nature of an entry is fully contained* within the entry
itself, and does not need rely on some context to give it proper meaning.
The context may give additional meaning, or it may not, but nonetheless it's
not part of the entry.

That's my sense of it.

e.

---

From: Henry Story <[email-masked]>
Date: Sun, 14 Nov 2004 17:39:41 +0100

On 14 Nov 2004, at 15:41, Bill de hÓra wrote:

>> entries, with a special entry being the head entry of the feed. That 
>> is the model I adopted in my latest attempts at modeling Atom in OWL.
>
> Not quite. I still don't see that either is a special case of the 
> other. I think the data structure for this is a 2-tuple feed(head, 
> list), not a 1-tuple feed(list) of uniform type. In my mind, the 
> second member of that tuple is a delayed list (i.e., a stream [1]), 
> not a set. But of course you could represent all the entries as a set, 
> but that's a math thing rather than a programming thing.

Ok. My way of putting it was a little too short hand. I was thinking of 
the model I had
represented by the following UML illustration

which in your notation is a 2-tuple feed(head, set), but I suppose 
could also represent feed(head,stream), which I in fact prefer.

> I recall Bob Wyman's analogy to a sliding window or some such 
> capturing my sense of a feed's entries perfectly.
>
>
>> "often", but not always. Perhaps you can reference exactly where 
>> Martin Fowler specifies one should be careful.
>
> [I'd like to but it I'm pretty sure it was in a yahoo group (I think 
> it was extremeprogramming) which are basically unsearchable in 
> reasonable time. All I'll say is I'm not making it up - there were two 
> code blocks that were doing essentially the same programmatic 
> operation; the deciding argument was to leave them as they were since 
> the blocks differed in intent at the application level. I remember 
> because it surprised me. Inheritance as reuse is (now) a 
> well-understood phenomenon in OO.]

[Yes. It is unbelievable that they should have allowed their search of 
the groups to get so bad. That is why I started the atom-owl group on 
groups-beta.google.com]

> 2-tuple. That the head looks like the the head of a list of entries is 
> a feature both of the XML snapshot you've been given and the vagaries 
> of English ;)

completely agree on this.

> Put it this way. my objections to treating the atom:head data 
> structure as a kind of atom:entry stands. Otherwise where you and 
> Robert and going is interesting.

Well I think that is just what Robert is proposing, and I am agreeing 
with. That the atom:head data structure is a kind of atom:entry data 
structure, or even is exactly that: an atom:entry.

The refactoring here came from taking the atom:entry structure and the 
atom:head structure and finding that they had most of their elements in 
common, and furthermore that there is no harm done when one further 
merges the differences into one.

Your objection was that such refactorings can sometimes be a bad idea. 
But exactly why they would not be good in this case is not clear. 
Neither is it clear what our refactoring has in common with bad 
examples of the application of this refactoring.

Such cons furthermore then have to be balanced agains the pros: such as 
the advantages in simplicity at the syntax, and maybe even the API 
level that may ensue from this. "It's all about the Entries stupid", 
sounds even truer now.

So the objection stands, but I think its legs are very very weak. It 
may want to sit down for a rest :-)

Henry

>
> On further reflection - atom:head might be a confusing name, 
> atom:header or atom:about might be better. No big deal, just an ob.
>
> cheers
> Bill
>

---

From: Henry Story <[email-masked]>
Date: Sun, 14 Nov 2004 17:53:44 +0100

I think there is a lot of strength to Eric's arguments below which 
could also be stated as "It's all about the Entries, stupid!" :->

But that is not the issue in this thread. The issue should rather be 
for Bob: would making the head data structure be a Entry data structure 
in any way affect the intent behind his pace.

And I don't think it does. If you really wanted a head in an Entry it 
would be just as simple to have a Entry contain a header property  to 
an Entry, than it would be to have it contain a header property 
pointing to a head structure.

So I don't think Bob need worry about this pace affecting his proposal.

Henry

---

From: Robert Sayre <[email-masked]>
Date: Sun, 14 Nov 2004 12:29:39 -0500

> my sense of a feed's entries perfectly.

I went for that analogy at first, as well. Now I think it's just a 
server-determined subset of a collection. You can characterize the 
results of a sequence of requests as a stream if you want, but that is 
true of any web resource.

In any case, this proposal was just a way to provide addressable 
metadata for feeds. People seem to be having an allergic reaction to it, 
  which is funny to me, since the use cases for entries themselves are 
very divergent.

There are other ways to do it, so it's not a big deal.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Sun, 14 Nov 2004 18:23:49 +0000

This Pace is awful. No one disagrees that head is very-much like an 
entry. But the thing is, that doesn't make it one. I don't even think 
you believe it is really an entry, otherwise you wouldn't have called 
it headentry. This Pace does nothing, literally nothing, in that 
afterwards we'll still have a head and a bunch of entries, we'll just 
be calling them by really non-sensical terminology. The conceptual 
argument is completely moot.

Why not adopt it anyway then? Because the real effect of the Pace is to 
arbitrarily remove our ability to differentiate the spec for an "entry" 
and a "headentry", and there's no reason to.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Sun, 14 Nov 2004 13:36:42 -0500

I don't understand anything you are writing. The effect of the Pace is 
negligible, yet it is awful? We need preserve the ability to 
differentiate the spec for entry and head, yet they are almost 
identical? The changes proposed are so small and people are flipping 
out. This is getting funny.

I will withdraw the Pace, and keep the Iron Curtain between head and 
entry. You will feel safe. Plus, I won't have to answer emails from you 
about it anymore. Everybody wins.

Robert Sayre

Graham wrote:

> you believe it is really an entry, otherwise you wouldn't have called it 
> headentry. This Pace does nothing, literally nothing, in that afterwards 
> we'll still have a head and a bunch of entries, we'll just be calling 
> them by really non-sensical terminology. The conceptual argument is 
> completely moot.
>

---

From: Henry Story <[email-masked]>
Date: Sun, 14 Nov 2004 20:11:10 +0100

On 14 Nov 2004, at 19:36, Robert Sayre wrote:

> entry. You will feel safe. Plus, I won't have to answer emails from 
> you about it anymore. Everybody wins.

Please don't withdraw the Pace. I am 100% behind it.
Others who think this is not such a bad idea please add your +1s to 
give Robert a little boost of confidence!

>> entry. But the thing is, that doesn't make it one.

What makes it one? Do you have special access to some Platonic realm 
where you can see exactly what a head structure is? Please let us know 
how and why it is not an Entry even though for all purposes it looks 
exactly like one.

>> I don't even think you believe it is really an entry, otherwise you 
>> wouldn't have called it headentry.

That is a complete misunderstanding of why Robert called the tag a 
headentry:
	1- to distinguish normal entries from this special one
	   Bill de Hora explained that very well recently as feed(head,stream) 
[1]
  	2- to distinguish the headentry property proposed from the previous 
head
		one with which he wishes to replace it. He even acknowledge that it 
would make
		no difference in the end if we returned back to calling it "head".

>>  This Pace does nothing, literally nothing, in that afterwards we'll 
>> still have a head and a bunch of entries, we'll just be calling them 
>> by really non-sensical terminology. The conceptual argument is 
>> completely moot.
>> Why not adopt it anyway then? Because the real effect of the Pace is 
>> to arbitrarily remove our ability to differentiate the spec for an 
>> "entry" and a "headentry", and there's no reason to.

I think that is exactly a very good reason to merge them. Let us 
simplify the spec, and if we find that a lot of problems end up 
surfacing because we failed to make a distinction, we can always go 
back to the previous state!

It seems a little silly to avoid simplifications to the spec, for some 
hypothetical distinction we may want to draw in the future.

>> Graham

[1] http://www.imc.org/atom-syntax/mail-archive/msg11563.html

---

From: Robert Sayre <[email-masked]>
Date: Sun, 14 Nov 2004 14:23:05 -0500

Henry Story wrote:

> Others who think this is not such a bad idea please add your +1s to give 
> Robert a little boost of confidence!
> 

Thanks for you support Henry, but my confidence is doing fine :)

It's just not that important. There are other ways to accomplish the 
same goal with a little cruft, and it's not worth sitting through a long 
argument about what's "natural", OO programming analogies, and the 
dissonance of a given proposal with the contents of Graham's mind.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Sun, 14 Nov 2004 21:40:35 +0000

> how and why it is not an Entry even though for all purposes it looks 

This illustrates exactly my point. If you define "entry" to mean what 
you want it to mean, you will of course always be right. Whether 
they're a "head" and an "entry", or a "special entry" and a "normal 
entry", conceptually you haven't changed things one bit, you've just 
changed the definition of "entry" we're using. Let's just call them 
"Thing 1" and "Thing 2".

> back to the previous state!

Well you can unify the syntax of Thing 1 and Thing 2 without having to 
call the head a "special entry".

> hypothetical distinction we may want to draw in the future.

They're are already several differences between the spec of Thing 1 and 
Thing 2. PEATWD removes them without concern for the technical 
implications.

Thank you for closing it Robert.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Mon, 15 Nov 2004 11:19:21 +1100

> hypothetical distinction we may want to draw in the future.

but it's not a simplification. it's shorter, maybe, but not simpler.

with it, every time we want to add some element or attribute to either the
head concept or the entry concept we have to take pains to spectext which it
is relevant to, and spectext it in a manner that makes sense in the context
of the superclass.

This is the consequence of the superclass for re-use antipattern.

e.