Subject: atom:category excludes atom:* children?

From: Bill de hOra <[email-masked]>
Date: Wed, 12 Mar 2008 16:51:00 +0000

Looking for a refresher on RFC4287 atom:category child constaints. Is it 
by design that atom:category cannot contain atom:* child markup? The 
spec text says nothing about restricting children of atom:category to 
non Atom markup, but here's the RNC says its illegal:

    atomCategory =
       element atom:category {
          atomCommonAttributes,
          attribute term { text },
          attribute scheme { atomUri }?,
          attribute label { text }?,
          undefinedContent
       }
    undefinedContent = (text|anyForeignElement)*
    anyForeignElement =
       element * - atom:* {
          (attribute * { text }
           | text
           | anyElement)*
       }

The feedvalidator follows the RNC and marks this construct as an error

     <category  term='holidays' label='Holidays'>
        <link rel='alternate' type='application/atom+xml'
            href='https://example.org/dehora/categories/holidays' />
     </category>

Why - it would be nice to supply a feed link for a category, and not do 
weird things with the scheme/term attributes. And I note that atom:link 
has the same restriction in the RNC.

Bill

---

From: James M Snell <[email-masked]>
Date: Wed, 12 Mar 2008 10:34:26 -0700

I noticed this also; in Abdera we simply ignore it and treat all child 
elements of atom:category and atom:link the same, regardless of namespace.

- James

---

From: Ben Ramsey <[email-masked]>
Date: Wed, 12 Mar 2008 13:38:36 -0400

> has the same restriction in the RNC.

What's wrong with using the scheme attribute to convey this information? 
Specifically, I use an AtomPub Category Document for my schemes. This way, I 
don't have to use a Feed to represent a listing of categories.

-- 
Ben Ramsey
http://benramsey.com/

---

From: Bill de hOra <[email-masked]>
Date: Wed, 12 Mar 2008 18:11:50 +0000

Ben Ramsey wrote:
>> Why - it would be nice to supply a feed link for a category, and not 
>> do weird things with the scheme/term attributes. And I note that 
>> atom:link has the same restriction in the RNC.
> 
> Specifically, I use an AtomPub Category Document for my schemes. This 
> way, I don't have to use a Feed to represent a listing of categories.

Two things:

1: the scheme attribute is a URI indicating the namespace, not a link.

2: the scheme is arguably not adequate to express something like a 
category feed; it does tell you the vocabulary/type of the category 
item, but not that there's an alternate/related resource.

Bill

---

From: "Brian Smith" <[email-masked]>
Date: Wed, 12 Mar 2008 11:25:03 -0700

Bill de hOra wrote:
> 2: the scheme is arguably not adequate to express something 
> like a category feed; it does tell you the vocabulary/type of 
> the category item, but not that there's an alternate/related resource.

I don't understand what you intend "alternate" to mean here. How can a feed be an alternate representation of a category? Is the feed supposed to list entries that have been marked with that category? Alternative categories that could be used instead? Something else?

Regards,
Brian

---

From: Antone Roundy <[email-masked]>
Date: Wed, 12 Mar 2008 13:24:46 -0500

> has the same restriction in the RNC.

 From RFC 4287, section 4.2.7:
    The "atom:link" element defines a reference from an entry or
    feed to a Web resource.

RFC 4287 defines the meaning of an atom:link with respect to an entry or
a feed, but not with respect to anything else.  Looking at your example
above, it's easy enough for a human to guess what you meant by the
atom:link...or at least to jump to a conclusion that might be wrong!

Speaking a little more generally, perhaps the reason no Atom markup is
allowed inside atom:category or atom:link is that the spec doesn't
define what such markup would mean.  If markup from another namespace is
put into either of those places, presumably the writer of the spec for
those elements would define what they meant in that place.

Antone

P.S. It seems like we had some discussion of this issue -- whether
atom:link should be allowed to appear in places other than directly
inside atom:feed and atom:entry -- specifically, I'd guess is might have
been about Person Constructs.

---

From: Bill de hOra <[email-masked]>
Date: Wed, 12 Mar 2008 21:31:18 +0000

> I don't understand what you intend "alternate" to mean here. How can a feed be an alternate representation of a category? Is the feed supposed to list entries that have been marked with that catego…

"related" might be better?

Bill

---

From: Ben Ramsey <[email-masked]>
Date: Wed, 12 Mar 2008 17:44:05 -0400

On 3/12/08 2:11 PM, Bill de hOra wrote:
>> What's wrong with using the scheme attribute to convey this 
>> information? Specifically, I use an AtomPub Category Document for my 
>> schemes. This way, I don't have to use a Feed to represent a listing 
>> of categories.
> 
> Two things:
> 

Thanks for this clarification. I'm starting to refactor some of my stuff so that 
the scheme is not relied upon to convey this kind of information. :-)

I think I've had a misinformed understanding of the scheme attribute because 
most examples I've seen use it in an AtomPub context, and the IRI of the scheme 
is also the URI of a Category Document.

-- 
Ben Ramsey
http://benramsey.com/

---

From: Antone Roundy <[email-masked]>
Date: Wed, 12 Mar 2008 17:46:51 -0500

Bill de hOra wrote:
>> I don't understand what you intend "alternate" to mean here. How can a 
>> feed be an alternate representation of a category? Is the feed 
>> supposed to list entries that have been marked with that category? 
>> Alternative categories that could be used instead? Something else?
> 

And here we see the problem using using atom:link this way -- there's no 
standard way to do it, and no standard interpretation of it.  Would a 
"related" feed be the feed of entries in that category, or some 
arbitrary feed on the same topic?

Perhaps it would be best to mint another link relation for the 
category's feed.  Or to use an extension attribute to point to it.

But there is the issue you of whether the RFC allows it.  As I read it, 
Atom markup in an Atom document may appear only in the places where the 
RFC says it can.  I see two possible ways around that (both of which I 
disagree with):

1) Since it's not EXPLICITLY stated that way, maybe it's not the case.

2) Atom markup in places not specified in the RFC could be treated as 
"foreign markup".  Section 6.4 says:

    Atom allows foreign markup anywhere in an Atom document, except where
    it is explicitly forbidden.

And section 6.2 says:

    unrecognized markup from the Atom vocabulary will be
    considered "foreign markup".

While I suppose one could argue that this means markup from this RFC 
appearing in places where this RFC doesn't allow it, I read it in 
context to be referring to markup added to the Atom vocabulary by future 
versions of the spec.

Section 6.2 says:

    Future versions of this specification could add
    new elements and attributes to the Atom markup vocabulary.

...which isn't exactly the same as saying that future versions could 
specify that existing elements and attributes can appear in places where 
they previously couldn't, but it seems to me that it's basically the 
same thing -- it's the prerogative of the WG to create future versions 
of the spec to make such changes.

Antone

---

From: Bill de hOra <[email-masked]>
Date: Wed, 12 Mar 2008 23:24:19 +0000

Antone Roundy wrote:
>>> I don't understand what you intend "alternate" to mean here. How can 
>>> a feed be an alternate representation of a category? Is the feed 

Sorry, I don't buy that as an argument against using atom:link here. If 
you want crisp denotations, use RDF or OWL or KIF, not the link rel 
registry.

> category's feed.  Or to use an extension attribute to point to it.

I don't agree, mainly because I doubt you could define "related" so that 
it excludes the option I gave.

> 1) Since it's not EXPLICITLY stated that way, maybe it's not the case.

No, because I see the spirit of the RFC as allowing what it does not 
explicitly disallow. Hence the RNC is non-normative.

> context to be referring to markup added to the Atom vocabulary by future 

I could agree with this...

> of the spec to make such changes.

...but this doesn't follow. "New Atom markup" meaning the same thing as 
"the current markup in an undefined place" isn't a reasonable 
interpretation.

I would say "huge gaping hole in the spec" were it not for my opinion 
that the WG worked on a default allow basis and the intent was never to 
restrict this kind of usage.

Bill

---

From: Sam Ruby <[email-masked]>
Date: Fri, 21 Mar 2008 07:36:01 -0400

> explicitly disallow. Hence the RNC is non-normative.

[snip]

> restrict this kind of usage.

Drats.  This thread has seemed to died down.  I had hopes...

As you say, the RNC is non-normative.  And consumers of Atom need to be 
aware that it is quite possible for subsequent RFCs to define new Atom 
vocabulary that is to be used as immediate children of atom:feed or 
atom:entry, let alone places which are intentional extension points.

Now, as to the feed validator, this is one of those rare times that it 
is at cross-purposes with the spec.  For the feed validator to be 
useful, it needs to be implemented with a "default disallow" policy lest 
it accept both atom:category and atom:catagory.

If there is any actual use of atom:link inside of atom:category, I'll 
downgrade this to a warning ("might be rejected by code that 
overzealously uses the provided RNC as a filter").  If there is any 
actual spec for how it is to be used, I'll eliminate the message 
completely for the use cases provided by the spec.

- Sam Ruby

---

From: Bill de hOra <[email-masked]>
Date: Fri, 21 Mar 2008 22:00:28 +0000

Sam Ruby wrote:
>> that the WG worked on a default allow basis and the intent was never 
>> to restrict this kind of usage.
> 

I'm not sure what you mean by spec, but it will be used. Example:

[[[
<entry xmlns='http://www.w3.org/2005/Atom'
     xmlns:media='http://search.yahoo.com/mrss/'>
     <id>http://example.org/data/jsmith/entry/ae34f5bc90f</id>
     <title type='text'>My Holiday Picture</title>
     <updated>2007-03-02T02:09:52.000Z</updated>
     <summary>My Holiday Picture</summary>
     <link rel='alternate' type='application/json'
      href='http://example.org/data/jsmith/entry/ae34f5bc90f?fmt=json' />
     <link rel='self' type='application/atom+xml'
         href='http://example.org/data/jsmith/entry/ae34f5bc90f'/>
     <link rel='edit' type='application/atom+xml'
         href='http://example.org/data/jsmith/entry/ae34f5bc90f' />
     <category  term='holidays' label='Holidays'>
         <link rel='related' type='application/atom+xml'
            href='http://example.org/data/jsmith/category/holidays' />
     </category>
     <link rel="edit-media" type="image/jpeg"
         href="http://example.org/photoedit/lisa.jpg" >
       <media:group>
        <media:content type='image/jpeg' medium='image'
         url='http://example.org/photos/lisa.jpg' >
       </media:content>
       <media:thumbnail height='128' width='128'
         url='http://example.org/thumbnail/lisa.jpg?tw=128&amp;th=128'>
       </media:thumbnail>
      </media:group>
     </link>
</entry>
]]]

It allows you to say, "this link of type application/atom+xml is related 
to this category".  IMO it's a spec bug to say it's invalid (ergo I 
don't see it as a warning either) - especially given what I see people 
doing with term/scheme to supply hypertext for a category.

If you need an ID to proceed, I can do that.

[Incidently, there is media RSS embedded inside atom:link in that 
example. I've been looking at media rss usage, and feel it's a better 
idiom - this way image links are not be hidden from basic readers.]

I also have another 'reuse' case, this time between app:* and atom:*:

[[[
POST http://example.org/user/jsmith/cat HTTP/1.1

<?xml version="1.0" ?>
<app:categories xmlns:app="http://www.w3.org/2007/app"
    xmlns:atom="http://www.w3.org/2005/Atom">
  <atom:category term="dog" label="Dog" >
    <atom:id>http://example.org/users/jsmith/entry/ae34f5bc90f</atom:id>
    <atom:id>http://example.org/users/jsmith/entry/ae22ghbc90f</atom:id>
  </atom>
</app:categories>
]]]

this provides a structure that we can send to a server saying, "please 
categorise the things with those ids using this category".

Conclusion: we can do a lot with the Atom/Atompub elements we already 
have, if we are allowed the freedom to compose the markup - call it 
"Freedom 0.1".

Bill

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 21 Mar 2008 15:35:46 -0700

Bill de hOra wrote:
> this provides a structure that we can send to a server 
> saying, "please categorise the things with those ids using 
> this category".

I tried doing something similar:

   <atom:category term="dog" label="Dog" >
     <atom:id>http://example.org/categories/dog</atom:id>
   </atom:category>

to mean "The category may be uniquely identified by the IRI http://example.org/categories/dog." Similarly, I tried using:

   <atom:author>
     <atom:id>http://briansmith.org/identitiy</atom:id>
     <name>Brian Smith</name>
   </atom:author>

to indicate that the author can be uniquely identified by the IRI http://briansmith.org/identitiy. 

> Conclusion: we can do a lot with the Atom/Atompub
> elements we already have, if we are allowed the
> freedom to compose the markup - call it "Freedom 0.1".

On the other hand, reusing the existing markup like this creates a lot of problems when people give different semantics to the same construct, as shown above. That is why I stopped trying to reuse any existing markup for new purposes.

By the way, I think it would often make more sense to say "please categorize the things with those ids using this category" by making each category its own AtomPub collection, and then POSTing links to the collection:

   POST /examples/categories/dog HTTP/1.1
   Host: example.org
   Content-Type: application/atom;type=entry
   
   <entry>
      <content src='http://example.org/users/jsmith/entry/ae22ghbc90f'/>
      ...
   </entry>

or:

   POST /exmaples/categories/dog HTTP/1.1
   Host: example.org
   Content-Type: text/uri-list
   
   http://example.org/users/jsmith/entry/ae22ghbc90f
   http://example.org/users/jsmith/entry/ae22ghbc90f

Then, you can keep up to date with what entries are in that category by polling the category's collection feed.

By the way, why did you decide to link to entries using their atom:id, instead of by their URI? There seems to be not much difference between:
   <category><id>http://example.org/users/jsmith/entry/ae22ghbc90f</id></category>
and:
   <category><link rel='categorized' href='atom:http://example.org%2Fusers/http://example.org/users/jsmith/entry/ae22ghbc90f'/>

In other words, when you link by atom:id, it is basically the same as linking using a new Atom-specific URI scheme. It seems simpler to give every resource a working HTTP URL, and then create hyperlinks using those URLs. The major problem with linking by atom:id is that atom:id is not a unique identifier (even though it is *supposed* to be), but a resolvable HTTP URL can be guarenteed unique as long as you control the servers that handle that URL. 

Regards,
Brian

---

From: Bill de hOra <[email-masked]>
Date: Fri, 21 Mar 2008 23:08:11 +0000

>      <atom:id>http://example.org/categories/dog</atom:id>

I like that. Part of me thinks atom:category could evolve into something 
that carries a lot of metadata; be a specialised entry if you like.

> On the other hand, reusing the existing markup like this 
> creates a lot of problems when people give different semantics 
> to the same construct, as shown above. That is why I stopped 
> trying to reuse any existing markup for new purposes.

Sure, but that's a generalization. I'd ask, where is the specific 
problem here?  Your first case, embedded atom:id, seems consistent to 
me. And so does an embedded atom:link in my category case. And as I said 
before, in the category case, it's preferrable to drilling links into 
@term or overloading @scheme to be a link. It's unfortunate that Atom 
categories aren't resources by design.

That said, I tend to think about semantics in the formal sense of the 
word; Atom doesn't have any.

> By the way, I think it would often make more sense to say 
> "please categorize the things with those ids using this 
> category" by making each category its own AtomPub collection, 
> and then POSTing links to the collection:

I didn't say it, but that example is taken from a document where 
categories have feeds (and are accessible as collections). Since what 
I'm doing is creating a relationship between two existing things, it 
felt more natural to use a distinct service for that.

> By the way, why did you decide to link to entries 
> using their atom:id, instead of by their URI? 

Because entries (and feeds) are identified using atom:id. Strictly 
speaking, I'm not linking here, I'm categorising.

> The major problem with linking by atom:id is 
> that atom:id is not a unique identifier (even though it 
 > is *supposed* to be), but a resolvable HTTP URL can be
 > guarenteed unique as long as you control the servers that
> handle that URL. 

Maybe; but I prefer to follow the spec text in this case rather than 
make assumptions about what might be the case.

Bill

---

From: James M Snell <[email-masked]>
Date: Fri, 21 Mar 2008 17:11:24 -0700

FWIW, while I quite like this use, there's an inherent problem in that 
"dumb clients" (atom clients that aren't aware of this particular 
extension) won't be able to do anything interesting with the link 
element embedded in the category.  More comments below.

> doing with term/scheme to supply hypertext for a category.

It's definitely better than bastardizing the scheme element to provide a 
dereferenceable URL. I would say that this definitely falls within the 
realm of the validator's "questionable use" warning... at least until 
there's spec text that describes the semantics.

> have, if we are allowed the freedom to compose the markup - call it 

We're also reusing some of the atom: and app: elements in interesting 
ways.  For instance, including atom:id in the app:category element so we 
can uniquely associate the collection with a specific feed.

- James

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 21 Mar 2008 17:35:40 -0700

Bill de hOra wrote:
> I like that. Part of me thinks atom:category could evolve 
> into something that carries a lot of metadata; be a 
> specialised entry if you like.

Right, my intent is to create a feed of entries that represent categories, people, and collections, which would basically replace service documents and category documents, and make user information discoverable. 

> me.

My point is that your example is using atom:category/atom:id in a totally different way than I was using it, and it seems really hard to predict when that will happen.

> And so does an embedded atom:link in my category case. 
> And as I said before, in the category case, it's preferrable to
> drilling links into @term or overloading @scheme to be a link.
> It's unfortunate that Atom categories aren't resources by design.

I agree, but there are a lot more alternatives. For example:

<link rel='category-schemes'
      href='http://exmaple.org/categories/schemes.feed'
      type='application/atom+xml;type=feed'/>

The link references an atom feed, where each category scheme is represented by an entry. We can link a category to a scheme matching its atom:category/@scheme to the scheme entry's atom:id. The category-schemes feed would be a metafeed as is common in GData, so that each scheme entry has a corresponding feed that lists the categories within that scheme. To avoid creating anything new, we will link <atom:categories> elements to entries in that feed, by matching the categories @term to the entry's <atom:id>. This would require atom:category/@term to be an IRI, but I don't think that is a big deal since there is a separate "label".

Example:

<feed>
  <content type='application/atom+xml'
           href='http://example.org/categories/tags.feed'/>
  <entry>
    <!-- Notice that no extensions are being used! -->
    <category scheme='http://example.org/categories/tags'
              term='http://example.org/categories/tags/holiday'
              label='Holiday'</category>
    ...
  </entry>
</feed>               

<feed>
  <id>http://example.org/categories/tags</id>
  <link rel='self'
        href='http://example.org/categories/schemes.feed'/>
  ...
  <entry>
     <id>http://example.org/categories/tags</id>
     <title>Tags</title>
     <content type='application/atom+xml'
              href='http://example.org/categories/tags.feed'/>
     ...
  </entry>
</feed>

<feed>
  <link rel='self'
        href='http://example.org/categories/tags.feed'/>
  ...
  <entry>
    <id>http://example.org/categories/tags/holiday</id>
    <link rel='self'
          href='http://example.org/categories/tags/holidays.entry'/>
    <title>Holidays</title>
    <content type='application/atom+xml'
             href='http://example.org/categories/tags/holidays.feed'/>
    ...
  </entry>
</feed>

Benefits of this approach:

* Every scheme is potentially an AtomPub collection, which means that categories within each scheme can be edited via AtomPub. The editability of a scheme can be determined by looking for an <app:collection> element within the scheme's feed. The mapping between categories and entries is simple:
   label  : atom:feed/atom:entry/atom:title
   term   : atom:feed/atom:entry/atom:id
   scheme : atom:feed/atom:id.

* Schemes can be explicitly added/edited/removed as well via AtomPub, using a similar mapping.

* There is no need to repeat the mapping information within each atom:category element, so it doesn't get in the way of clients that don't understand the extension.

Drawbacks:

* The default scheme cannot be used, since atom:category/@scheme would have to be a IRI.

* Category terms have to be IRI's for the same reason. You could use a separate nested <atom:id> instead, but then @term becomes redundant.

* You might not want to force clients to navigate from the orignal feed -> schemes -> categories -> category-specific feed. You could provide a shortcut:

    <category scheme='http://example.org/categories/tags'
              term='http://example.org/categories/tags/holiday'
              label='Holiday'</category>
       <link rel='self'
             href='http://example.org/categories/tags/holidays.feed'
             type='application/atom+xml;type=feed/>
       <!-- and/or -->
       <link rel='self'
             href='http://example.org/categories/tags/holidays.entry'
             type='application/atom+xml;type=entry/>
    </category>

- Brian

---

From: "Brian Smith" <[email-masked]>
Date: Fri, 21 Mar 2008 17:54:56 -0700

Brian Smith wrote:

Here is a corrected example:

>         type='application/atom+xml'

- Brian

---

From: James M Snell <[email-masked]>
Date: Fri, 21 Mar 2008 18:50:11 -0700

> My point is that your example is using atom:category/atom:id in a totally different way than I was using it, and it seems really hard to predict when that will happen.

Correct; this is the crux of the problem. Sam and I went around on these 
kinds of issues before with the Feed validator.  While using atom:id or 
atom:link in the ways discussed in this thread and not technically in 
valid, they are questionable given the fact that there is no spec text 
anyone can point to.  Whose usage is correct?  There's no way of knowing.

- James

---

From: "ext James M Snell" <[email-masked]>
Date: Fri, 21 Mar 2008 17:11:24 -0700

- James

---

From: Bill de hOra <[email-masked]>
Date: Sat, 22 Mar 2008 11:25:12 +0000

James M Snell wrote:
> 
> 
> Brian Smith wrote:
>> [snip]
>> My point is that your example is using atom:category/atom:id in a 
>> totally different way than I was using it, and it seems really hard to 
>> predict when that will happen.
>> [snip]
> 

I don't agree there's a distinction.

In one case I embedded atom:id in a category and POSTed that to a server 
to say categorise these things. In the other case Brian embedded a link 
in category to say "The category may be uniquely identified by the IRI" 
on GET. What would break?

Let me it another way - do we need to make categories resources and 
provide them with atom:ids? If so, let's do that.

Bill

---

From: Bill de hOra <[email-masked]>
Date: Sat, 22 Mar 2008 11:37:44 +0000

> there's spec text that describes the semantics.

Atom has no semantics, and that's a conscious decision of the WG, going 
back as far as rejecting semweb technology. We also organise out markup 
fairly differently to the RDF guys - they explicitly hang everything off 
a URI; we don't and because of that this kind of issue will come up 
every time some wamts to take an Atom construct and make a resource out 
of it (root problem - we have links /and/ ids). The validator then, and 
imvho, has no business nosing around denotational semantics beyond 
saying "no notation with denotation!" when it sees an atom:id in a new 
place.

I think what's needed here is a) a definition of atom:id wrt 
atom:category, b) a uniform means of categorising entries.

Bill

---

From: "ext Bill de hOra" <[email-masked]>
Date: Fri, 21 Mar 2008 22:00:28 +0000

[[[

[[[

<?xml version="1.0" ?>

Bill

---

From: "ext Brian Smith" <[email-masked]>
Date: Fri, 21 Mar 2008 15:35:46 -0700

<atom:author>

   
   <entry>

or:

Regards,
Brian

---

From: "Brian Smith" <[email-masked]>
Date: Sat, 22 Mar 2008 08:13:52 -0700

Bill de hOra wrote:
> Let me it another way - do we need to make categories 
> resources and provide them with atom:ids? If so, let's do that.

RFC 4287 says:

    The "term" attribute is a string that identifies the
    category to which the entry or feed belongs. Category
    elements MUST have a "term" attribute.
 
   The "scheme" attribute is an IRI that identifies a
   categorization scheme.  Category elements MAY have a
   "scheme" attribute.

In other words, categories are (supposed to be) uniquely identified by @term, not by (@scheme, @term). So, terms must be globally unique to be unambiguous and so they SHOULD (IMO) be IRIs already.

- Brian

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Mar 2008 09:44:33 -0700

> In other words, categories are (supposed to be) uniquely identified by @term, not by (@scheme, @term). So, terms must be globally unique to be unambiguous and so they SHOULD (IMO) be IRIs already.

There was never any intent to make categories globally unique; nor is 
there any justification to requiring them to be so.  The scheme 
attribute tells the processor how to interpret the value of term, which 
can be any string value, including an IRI.  In my application, I can 
define a scheme value that indicates that the term is a globally unique 
IRI.  I could even define a scheme that indicates that the term is a URI 
that can be dereferenced.  Processors that understand the scheme will be 
able to process it accordingly.

e.g.

<category
   tag="nonunique" />
<category
   scheme="http://example.org/number"
   term="123" />
<category
   scheme="http://example.org/unique"
   term="tag:example.org,2008:/unique" />
<category
   scheme=http://example.org/url"
   term="http://example.org/foo" />

- James

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Mar 2008 09:54:45 -0700

Bill de hOra wrote:
> 
> James M Snell wrote:
> 
>> It's definitely better than bastardizing the scheme element to provide 
>> a dereferenceable URL. I would say that this definitely falls within 
>> the realm of the validator's "questionable use" warning... at least 
>> until there's spec text that describes the semantics.
> 

a) is what I meant by "semantics"... poor word choice on my part.

With regard to b) The scheme attribute works very well as a means of 
differentiating categorization methods.  We may very well need to come 
up with some standardized categorization schemes.

- James

---

From: "Brian Smith" <[email-masked]>
Date: Sat, 22 Mar 2008 10:23:33 -0700

James M Snell wrote:
> Brian Smith wrote:
> > In other words, categories are (supposed to be) uniquely 
> > identified by @term, not by (@scheme, @term). So, terms must 
> > be globally unique to be unambiguous and so they SHOULD (IMO) 
> > be IRIs already.
> 
> There was never any intent to make categories globally 
> unique; nor is there any justification to requiring them to 
> be so.  

I didn't say that categories were required to be unique. I said that if you want to uniquely identify a category, it has to have a unique term. If you are happy with them being ambiguous, then uniqueness isn't necessary. 

> The scheme attribute tells the processor how to 
> interpret the value of term[...]

The specification does not say anything about how to interpret terms, only that categories are identified by terms.

> [...] which can be any string value, including an IRI.

I know any string value can be used (even the empty string). But I still recommend that people use IRIs as for the term attribute to avoid any confusion.

I can see why you might think that the authors of the specification intended to write the opposite of what they wrote. But, I doubt that all the people that have reviewed the specification overlooked such an obvious contradiction. It is better to assume that the specification says what it means. Regardless, It is prudent to apply the robustness principle here: when creating categories, ensure the category is uniquely identified by the term attribute (interpret the specification as it is written), and when accepting categories from others, copy them unmodified (if the producer doesn't take the spec literally, you should also tolerate that as much as possible). If you do that, you are unlikely to run into any problems.

- Brian

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Mar 2008 11:10:14 -0700

Brian Smith wrote:
> I can see why you might think that the authors of the specification intended to write 
> the opposite of what they wrote. But, I doubt that all the people that have reviewed
> the specification overlooked such an obvious contradiction. It is better to assume 
> that the specification says what it means. Regardless, It is prudent to apply the 
> robustness principle here: when creating categories, ensure the category is uniquely 
> identified by the term attribute (interpret the specification as it is written), and 
> when accepting categories from others, copy them unmodified (if the producer doesn't 
> take the spec literally, you should also tolerate that as much as possible). If you 
> do that, you are unlikely to run into any problems.
> 

Heh.. I think I'm familiar enough with the spec text to know exactly 
what it says.  But let's look at the text again...

      The "term" attribute is a string that identifies the category to
      which the entry or feed belongs.  Category elements MUST have a
      "term" attribute.

      The "scheme" attribute is an IRI that identifies a categorization
      scheme.  Category elements MAY have a "scheme" attribute.

Notice that the word "unique" isn't used.  In fact, the word "unique" is 
used only twice within the entire spec, in section 4.2.6 re: atom:id. 
So if we want to play the "interpret the specification" game, then yes, 
the term is used to identify the category, but it is not required, 
recommended or even subtlety suggested that the term should be unique.

Regarding the scheme attribute and the "interpretation" of categories... 
  You're right, Atom does not define how to interpret terms.  What it 
does do is provide the scheme attribute so the categorization scheme can 
be identified.  It is the categorization scheme that defines how to 
interpret the term... which is what I said.

For instance, suppose I want to assign a Library of Congress 
categorization to an entry...

   <category
     scheme="http://www.loc.gov/aba/cataloging/classification"
     term="QA76.75-76.765" />

While the term appropriately identifies the category, there's absolutely 
no way a client can interpret the term without being familiar with the 
Library of Congress classification system.  The fact that the term 
happens to be unique within the LoC scheme is irrelevant as far as Atom 
is concerned.

Another important point is that an entry can contain multiple category 
elements that use the same term but have different schemes.  For all 
practical purposes, these are two completely different categories.  The 
term identifies the category within the scope of the categorization scheme.

   <entry>
     ...
     <category scheme="http://example.org/foo" term="baz" />
     <category scheme="http://example.org/bar" term="baz" />
     ...
   </entry>

- James

---

From: Antone Roundy <[email-masked]>
Date: Sat, 22 Mar 2008 13:58:10 -0500

Brian Smith wrote:
 > The specification does not say anything about how to interpret terms,
 > only that categories are identified by terms.

     The "term" attribute is a string that identifies the
     category to which the entry or feed belongs.

I can see how in isolation you might read that to mean, for example, 
that @term="Green" identifies (or should identify) one global category, 
but read along with the next section, I don't see how that could make sense:

If @term alone were intended to uniquely identify a category, why have 
@scheme at all?  And why didn't we create or reference a category scheme 
for everyone to share?

I'm quite certain our intent was that absent @scheme, @term would 
identify the category of the entry only within the context of the 
containing feed.  If @scheme is specified, @term would identify the 
category within the specified scheme.

Therefore, unless for some reason you want to omit @scheme, I see no 
need to use IRIs for @term.

Antone

---

From: "Brian Smith" <[email-masked]>
Date: Sat, 22 Mar 2008 13:21:00 -0700

Antone Roundy wrote:
> If @term alone were intended to uniquely identify a category,
> why have @scheme at all? And why didn't we create or
> reference a category scheme for everyone to share?
>
> Therefore, unless for some reason you want to omit @scheme, I 
> see no need to use IRIs for @term.

I agree that @scheme seems pretty useless as it is defined in the specification. Luckily, if you avoid using @scheme, and you use IRIs for @term, you can avoid worrying about it.

Regards,
Brian

---

From: Antone Roundy <[email-masked]>
Date: Sat, 22 Mar 2008 16:16:58 -0500

Brian Smith wrote:
 > I agree that @scheme seems pretty useless as it is defined in the
 > specification. Luckily, if you avoid using @scheme, and you use IRIs
 > for @term, you can avoid worrying about it.

Just to be sure we're clear, I DON'T think that it's useless -- I agree 
only that if the spec meant what you're saying it means, @scheme would 
be worthless.

But I think you're reading a different meaning into it than we intended 
when we created it.  Which is more likely:

1) Everybody working on the spec completely missed the fact that @scheme 
was useless and the fact that the definition of @term said nothing about 
how it should be sufficient by itself to uniquely identify a category, 
and should be constructed in a way that prevented collisions (even 
though we put a lot of effort into working out how atom:id would act as 
a unique identifier for a feed or entry).  And it didn't occur to anyone 
that since we wanted a globally unique identifier for a category, we 
could use atom:id instead of @term.

2) @term was intended to identify a category within a defined scheme 
which was indicated by @scheme, or within an ad hoc scheme when @scheme 
was absent.

Especially since I believe I remember the discussion running along the 
lines of #2, I find #1 highly implausible.

Antone

---

From: Bill de hOra <[email-masked]>
Date: Sun, 23 Mar 2008 00:48:48 +0000

> I agree that @scheme seems pretty useless as it is defined in the specification. Luckily, if you avoid using @scheme, and you use IRIs for @term, you can avoid worrying about it.

It's not useless; it's useful for quantification over a set terms (that 
is, "for all terms in the scheme X, Y holds true"). That's it's not good 
for denotation, sure; it wasn't designed for that.

Bill

---

From: Bill de hOra <[email-masked]>
Date: Sun, 23 Mar 2008 01:01:34 +0000

>> [...] which can be any string value, including an IRI.

[I had to manually indent your mail]

> I know any string value can be used (even the empty string). But I still 
> recommend that people use IRIs as for the term attribute to avoid any confusion.

Why? By your logic an IRI would just be a string here.

> I can see why you might think that the authors of the 
> specification intended to write the opposite of what they 
> wrote. But, I doubt that all the people that have reviewed 
> the specification overlooked such an obvious contradiction. 
> It is better to assume that the specification says what it means. 
> Regardless, It is prudent to apply the robustness principle here: 
> when creating categories, ensure the category is uniquely identified 
> by the term attribute (interpret the specification as it is written), 

That's not what the spec says.  What spec text allows a client to assume 
a term is globally unique?

> and when accepting categories from others, copy them unmodified (if 
> the producer doesn't take the spec literally, you should also tolerate 
> that as much as possible). If you do that, you are unlikely to run into 
> any problems.

I can't reconcile your wish that terms are globally unique to the spec 
text, which does not say that. But categories have similar problems to 
XML namespaces and I like that you're asking the hard questions.

Bill

---

From: "Brian Smith" <[email-masked]>
Date: Sat, 22 Mar 2008 19:15:26 -0700

Bill de hOra wrote:
> Brian Smith wrote:
> That's not what the spec says.  What spec text allows a 
> client to assume a term is globally unique?

The spec says:

   The "scheme" attribute [...] identifies a categorization scheme. 

We seem to all be unanimous that here "identifies" means "uniquely identifies". But, immediately prior to that we have:

   The "term" attribute [...] identifies the category to
   which the entry or feed belongs. 

Here, apparently, "identifies" does not mean "uniquely identifies" even though the sentence structure is exactly the same.

I dug around and saw that in draft 04 of the spec., the term attribute was defined with different language:

   The "term" attribute [...] identifies the category
   within the categorization scheme to which the entry
   or feed belongs.

It is poorly worded but I think it is clearer than what the spec. says now.

I can see that there is consensus here (that I am wrong :), so I won't argue further about what the spec. says vs. what it intends to say. If there is some errata mechanism for the specification, we should consider adding a clarification there.

See also:
http://www.mail-archive.com/[email-masked]/msg06874.html
http://tools.ietf.org/html/draft-ietf-atompub-format-04#section-3.7.1

Regards,
Brian

---

From: James M Snell <[email-masked]>
Date: Sat, 22 Mar 2008 20:34:18 -0700

> We seem to all be unanimous that here "identifies" means "uniquely identifies". But, immediately prior to that we have:

I'm not sure what thread you've been reading, but in the thread I'm 
reading you seem to be the only person here thinking that "identifies" 
means "uniquely identifies".  The scheme attribute value is an IRI; and 
it would make exceedingly little sense for two categorization schemes to 
share the same identifier but the RFC does not require or even hint that 
the identifier should be unique.

> Here, apparently, "identifies" does not mean "uniquely identifies" even though the sentence structure is exactly the same.

The sentence structure is the same because, in both cases, neither 
identifier is required to be unique.

> It is poorly worded but I think it is clearer than what the spec. says now.

That's irrelevant.  Draft -04 is not RFC 4287.

> I can see that there is consensus here (that I am wrong :), so I 
> won't argue further about what the spec. says vs. what it intends 
> to say. If there is some errata mechanism for the specification, 
> we should consider adding a clarification there.
> 

There's nothing to clarify.  The spec is clear.  It says exactly what 
was intended.  There is no errata to document.

- James

---

From: Bill de hOra <[email-masked]>
Date: Sun, 23 Mar 2008 18:55:14 +0000

Brian Smith wrote:
> We seem to all be unanimous that here "identifies" means "uniquely identifies". 

I'm not. To paraphrase yourself, it means what it says it means.

> But, immediately prior to that we have:
> 

Again, it means what it says it means.

> It is poorly worded but I think it is clearer than what the spec. says now.

Sorry, no. The only problem with the spec in this case, is that you're 
to retroactively imbue meaning to it, to support an argument you want to 
be the case.

> I can see that there is consensus here (that I am wrong :), 
> so I won't argue further about what the spec. says vs. what 
> it intends to say. If there is some errata mechanism for the 
> specification, we should consider adding a clarification there.

That's a better tack that redefinition.

Bill