On Jun 3, 2009, at 9:15 AM, Julian Reschke wrote:
Nikunj R. Mehta wrote:
...
Assuming that the contents of the link element are inlined content
are adding an extension without explicitly identifying it; this
may conflict with future uses.
Our proposal is /the/ future use, so I don't see how it can
conflict with future uses. It is our intention to promote an
extension of Atom. By submitting the I-D to the IETF and by
bringing this discussion to atom-syntax, we have made the intention
quite clear, don't you agree?
...
I think the point is that this is not an extension point for general
use; thus if it is to be used it would need to be done by a spec
that's on the standards track, and updates RFC4287. For that you'll
likely need a WG to reach the consensus that *this* is the way to go.
The IETF AD for Applications has already suggested that she would be
supportive of a new WG to look at this issue. Frankly, IETF needs to
look at the issue of hierarchical representation in Atom. Frankly,
there is a lot of experience in dealing with hierarchy in Atom/
AtomPub. It would be futile to think otherwise. As examples, take a
look at Google's GData APIs and Microsoft's ADO.NET use of Atom/AtomPub.
I was dissuaded from submitting the atompub-hierarchy I-D along
standards track, but it looks like the right way to proceed. Of
course, that also means getting together a new WG. Would you be
willing to help form such a WG?
It is a different story if Atom cannot be extended as we wish. May
be it would be useful if you or others who claim that our approach
is wrong can explain what is the process for extending Atom. Is it
creating a brand new working group?
The Atom format has extension points that allow distributed
extensibility, but the content of atom:link isn't one of them, as
far as I can tell.
It was never the intention of atom-hierarchy I-D to perform
independent extension of Atom. Therefore, I don't see this as a problem.
Nikunj
http://o-micron.blogspot.com
