On Thu, Jun 4, 2009 at 6:50 PM, Mark Nottingham<[email protected]> wrote: > > > On 05/06/2009, at 9:38 AM, Nikunj R. Mehta wrote: > >> On Jun 4, 2009, at 4:14 PM, Mark Nottingham wrote: >> >>> >>> On 05/06/2009, at 1:56 AM, Nikunj R. Mehta wrote: >>> >>>> On Jun 3, 2009, at 6:32 PM, Mark Nottingham wrote: >>>> >>>>> None of this is your fault; the extension model in Atom isn't terribly >>>>> well-specified. >>>>> >>>> >>>> I don't know of anyone else complaining about this. I am not sure this >>>> is the general perception. Can you provide some evidence to back up this >>>> claim? >>> >>> *shrug* It's just an opinion. However, Atom bucks the trend of >>> well-designed IETF protocols with its "everything is extensible" approach; >>> by not designating *how* to extend each possible point, and how that >>> extension is managed, it leaves extension open to interpretation (as we see >>> here). >>> >>> I think this might be because at the time Atom was written, the >>> extensibility of XML was considered a good thing, and the unspoken reasoning >>> was "the more extensibility, the better." In practice, I don't think this is >>> working; there's been lots of discussion along these lines on-list (e.g., >>> whether to use attribute extensibility, whether to use entry extensions or >>> atom:content). >> >> Hmm... while Atom's current extensibility points are sufficient for what >> we are attempting to do, I interpret your points as more general issues with >> XML, rather than specifically with Atom. I also interpret broken >> extensibility along the lines of XSD rather than having too many options. >> However, I can now see your perspective as well. > > XML is just a metamodel and syntax for expressing a language; it's up to the > language to define how to extend itself... > > >>>>> Regardless of how you serialise the hierarchy, at some point the >>>>> document you're going to end up with will not be very useful to a generic >>>>> Atom processor (as deployed today), because the majority of the >>>>> information >>>>> is in extensions. When that happens, it's worth considering minting a new >>>>> media type to identify the document, so that people can differentiate >>>>> them. >>>> >>>> I don't see any reason to mint a new media type for dealing with >>>> extensions such as the one I am proposing in atom-hierarchy-ID. Can you >>>> explain what will break and in what way we are creating an incompatible >>>> extension of Atom to force us out of application/atom+xml? >>> >>> >>> I didn't say it would become incompatible; I said that at some point, you >>> extend a document so much that it's no longer useful or meaningful to a >>> generic processor. At that point, it's worth *considering* (note the >>> emphasis, please) identifying the new format with a new media type, to make >>> it distinct from the old one. >> >> IMHO, anyone would be reluctant to consider a new media type for XML feeds >> if the kind of reaction about the ownership and meaning of text/html is any >> indication. We should exhaust all options before resorting to minting a new >> media type. And the kind of extension we are suggesting seems legal, >> prevalent, and useful. Also, it is primarily additional semantics that are >> compatible with existing semantics. So I was a little surprised to see you >> projecting as far out as you did. But I have noted your emphasis and, >> hopefully, communicated my concerns too. > > > I think HTML is a different case; you can extend it with new elements that > have no meaning in HTML, but it can still be functional HTML, in particular > because you can embed scripts to interpret those new elements. Atom doesn't > have this option, and is more structured, as well as more intended for > machine interpretation in the cases that people are talking about here. > Distinct media types are useful, and we shouldn't be afraid of them, except > perhaps where they cause legacy problems (as with HTML). > > My understanding was that the utility of this extension was being able to > express graphs of entries in a single document; that's why it sounded so > different to me. (as opposed to just adorning a feed with additional > metadata, which is the typical use case for extensions in Atom). Also, as I > think I said earlier, there are a lot of things that could be improved in > Atom (especially for the machine-oriented cases) if we had a chance to do > that. >
I hope I'm not too far off w/ this, but it seems to me there are a couple distinct concerns in this thread: First is a need for what is essentially multiple atom:content elements in an entry. atom:link seems like a logical home for that content (given that we can assign an appropriate @rel). The fact that it may or may not contain a hierarchical data structure is immaterial to the semantics of the atom:entry itself. Second, there is a need to express hiearchical relationship between entries and entries, entries and feeds, and feeds and feeds. Link semantics fit the bill quite well and the proposed @rel values in the hierarchy ID cover the need. I'd agree with Nikunj that this is not so dramatic a change that new media types need to be considered. It feels more like a tweak to me, and I do not see much difficulty at all in using my current tools for parsing or producing such atom documents. My previous championing of Google's feedLink is moot since it does not appear to be an easier "sell" than atom:link content (my main motive), nor as useful per comments from others on this thread. --peter keane > Anyway, sounds like we understand each other. > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > >
