On Friday, January 7, 2005, at 09:33 PM, Eric Scheid wrote:
On 8/1/05 11:03 AM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:Ah, good point--we have indeed built something that isn't a pure tree structure, but we haven't explicitly stated anything general about whether extensions are allowed to work that way or not. So do we want to say something along the lines of "Except as otherwise provided by the Atom specification, elements and attributes affect the meaning only of their (immediate?) parent elements. For example, the values of extension elements appearing as children of the feed and head elements are not inherited by the feed's entries." I'd be in favor or some sort of language clarifying the point that exceptions to the pure tree structure are only allowed where defined by the Atom specification. If we DO want to allow extensions to violate the pure tree structure, we should to define a mechanism for doing so such as one (or more) of the following:(This seems so intuitively obvious that I wouldn't think people would make XML that didn't work this way, but from the sound of it, there are examples out there of XML where child elements aren't related to their parents. I for one would understand the importance of making this explicit if I could see such examples).
it's often not so much a case of breaking a parent-child relationship, but
asserting a sibling relationship ... even in atom, we already have
/feed/head/author which applies to /feed/entry.
What happens when some moblogger wants to put <geo:coords> into /feed/head
but have it apply to all /feed/entry except where there are specific
<geo:coord> for a given <entry>?
1) Define a method of explicitly stating that an element appearing at the feed level is a default value for entries that don't override it. A method of expressing "no value" for arbitrary extension elements, to override the default, would be necessary.
2) Define a method of assigning an identifier to an element which could be referenced from elsewhere irrespective of the tree structure (RDF provides one such method).
3) Have a "mustUnderstand" mechanism, and require any extension which violates pure-tree structure to be marked "mustUnderstand".
I think that over time, I've been an advocate of examples of each of the foregoing. Both #1 and #2 would make processing Atom somewhat more complex, so I could take them or leave them both without complaint. I don't see a downside to #3 (either for this specific purpose, or more generally as a way to avoid misunderstanding of extensions when such misunderstanding has potential for causing problems).
