Apologies for the rubbish timing, but I've been reviewing section 6, and found a number of problems.
Firstly, there are some mismatches between the RelaxNG grammar and the specification text. I know that the RelaxNG grammar isn't normative; but this doesn't mean that it can be contradictory: a) Section 6.4 omits atom:source as a valid location for Metadata Extensions, but it is allowed by the RelaxNG in 4.2.11. I believe that the RelaxNG reflects our intent to allow extensions to be preserved in atom:source. b) Section 6.4.1 and Section 6.4.2 don't place any restrictions on what elements may be used as Metadata Extensions, but the RelaxNG grammar explicitly excludes elements in the Atom namespace. The Atom namespace should be reserved for future forwards-compatable revisions of Atom. I actually raised these issues before the new draft was published but I didn't receive any comments. I am surprised that nothing has been fixed, these two issues are simply bugs. c) It isn't the intent of Section 6.4.1/6.4.2 that namespace declarations should be considered among the "attributes and child elements" that determine whether an extension is "Simple" or "Structured". This should be made explicit, many implementors don't have control over their placement (luckily). I also have some problems with the structure of the whole section: Section 6.3 describes "unknown foreign markup" as markup not defined by the specification and describes how it should be processed; but Section 6.4 specifies the behaviour of another type of markup. Is Section 6.4 markup described by the specification, and therefore distinct from "unknown foreign markup"? If so why is it described after describing the catch-all - this non-linearity is very confusing. Or is it a subset? I think that the definition is rather ambiguous. I find the distinction between "metadata elements", "foreign markup", and "unknown foreign markup" to be extremely confusing. I wouldn't be surprised if a Venn Diagram of them was totally different to my interpretation. It would be better if this section was re-ordered, so that the catch-all definition of non-Metadata Element extensions was placed after the definition of Metadata Elements. The two subsections of Section 6.4 are intended to describe the two subclasses of Metadata Element. It would make more sense if the terminology for these subclasses was uniform. Why not call them "Metadata Extensions", "Simple Metadata Extensions", and "Structured Metadata Extensions"; rather than "Metadata Elements", "Simple Extension Elements", and "Structured Extension Elements". I think it is insufficient to describe these subclasses purely in terms of their syntactic characteristics, rather than in terms of their intent. It would be beneficial for publishers if a paragraph was introduced into Section 6.4 to describe why a publisher/extension author would favor one of these classes. The intent is that a given extension would belong to a fixed class, and the Simple class is designed to offer the advantages of easy generic processing by simpler implementations (eg storage by servers in custom attributes), amongst other things. Finally, on a more fundamental level, I am worried by the class of markup that is an extension, but isn't a "Metadata Element". This, I think, is limited to children of atom:link, and additional attributes on atom elements. If this markup was reserved for future revisions of Atom, that would be fine, but it doesn't appear to be the case - I can't really tell? Acording to the charter Atom should have a seperate model and syntax. Metadata Elements were proposed to ensure that extensions could be part of the model, so that they could be represented in RDBMS/OO/RDF/WebDAV implementations as custom properties. This other class of extension, if it is intended to be one, can only be represented as part of the Atom's XML syntax. To provide support for extensions that use this class of markup would require changes to every stage of the publishing and processing process. A better alternative would be if these attribute extensions were just treated as an alternative way of expressing Simple Metadata Extensions - at least then some generic support for them could be implemented. Either that or they should be reserved for use by future Atom specifications. There are other areas that should be clarified too. I assume that "Atom markup vocabulary" is intended to be current and future elements in the Atom namespace, and un-namespaced attribtues on Atom elements, but this is just my guess, it isn't defined in the specification. -- Dave
