Sam Ruby wrote:
Bill de hOra wrote:
No, because I see the spirit of the RFC as allowing what it does not
explicitly disallow. Hence the RNC is non-normative.
[snip]
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.
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.
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&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
![http://example.org/photoedit/lisa.jpg"](http://example.org/photoedit/lisa.jpg"){kind=link}
