Tim Bray wrote:
http://www.intertwingly.net/wiki/pie/PaceExtendingAtom
+1 to PaceExtendingAtom. These comments are mostly editorial.
"9.2 Extensions To the Atom Vocabulary
Future versions of this specification may add new elements and attributes to the Atom markup vocabulary."
The term 'vocabulary' should be defined in parens somewhere - I assume it implies all the names in a given namespace... ?
Please change,
"Software written to conform to this version of the specification will not be able to process such markup correctly and, in fact, will not be able to distinguish it from a markup error"
above, to,
"Software written to conform to this version of the specification will not be able to process such markup correctly and might not be able to distinguish it from a markup error"
I'm pretty sure I can write code to not treat 'foreign elements' as markup errors in the absence of ver/ext policies. The current text overstates the case. Anyway, the last sentence below,
"9.3 Software Processing of Foreign Markup
Software processing an Atom Document which encounters foreign markup in a location that is legal according to this specification MUST NOT stop processing or signal an error. It may be the case that the software is able to process the foreign markup correctly and does so. Otherwise, such markup is termed "unknown foreign markup"
contradicts the "will not be able to distinguish it from a markup error" assertion. Otherwise, I don't see a need to distinguish 'foreign markup' and 'unknown foreign markup'. It's overcomplicated - either you spec to allow new stuff to pass at certain points or you spec to fail if new stuff attempts to pass. Speccing to allow stuff to pass where it couldn't pass before implies a new vocabulary.
cheers Bill
