Extensions containing Atom elements (was: Obs on format-07)
David Powell wrote:
- in 6.4; extension schema allow the use of the atom namespace as child
elements of the extension. I do not recall this being discussed, but
personally am +1 to it.
Yeah, I'm ok with it too. I'm not sure why anyone would want to do it,
but the spirit of Structured Extension elements was that (almost)
anything goes.
Sounds right to me. If I'm not mistaken, we'll need to define
'anyElement' in the RNC as follows:
anyElement =
element * {
(attribute * { text }
| text
| anyElement)*
}
Robert Sayre
Re: Obs on format-07
At 4:37 PM -0400 4/10/05, Robert Sayre wrote: ** Figures Please add figure captions for all samples, bnf and rnc fragments. If you require someone to do this, I will do it. I'm having trouble seeing the benefit here. They might work well in the HTML version, but I don't think they do in the text version. I agree with Robert here. If the samples and fragments appear just after the paragraph talking about them, I would find the figure names more distracting than useful. I didn't trip over anything when reading the latest draft. Could you show me an example where it would help the text version? Agree: please point to where they might be useful. A little judicious use is fine, but having every fragment labelled would probably be overkill. --Paul Hoffman, Director --Internet Mail Consortium
Re: Obs on format-07
Robert Sayre wrote: Bill de hÓra wrote: ... ** ABNF Drop. ... reason: ABNF is used in one place: 4.2.9.2 The "rel" Attribute, p1 and referred to in 3.3. It's incidental enough to be dropped. I agree with this one now. The other specs use the older ABNF spec anyway. ** Figures Please add figure captions for all samples, bnf and rnc fragments. If you require someone to do this, I will do it. I'm having trouble seeing the benefit here. They might work well in the HTML version, but I don't think they do in the text version. Could you show me an example where it would help the text version? I can look at a caption to tell me it's a rnc fragment, without doing a double or treble take. There are captions in the spec anyway, just not 'marked up' as such: [[[ 3.1.1.2 HTML Example atom:title with HTML content: ... Less: < ... ]]] But truth be told, I see no need to justify their inclusion, any more than one would need to justify the inclusion of a TOC or page numbers. cheers Bill
Re: Obs on format-07
Bill de hÓra wrote: ... ** ABNF Drop. ... reason: ABNF is used in one place: 4.2.9.2 The "rel" Attribute, p1 and referred to in 3.3. It's incidental enough to be dropped. I agree with this one now. The other specs use the older ABNF spec anyway. ** Figures Please add figure captions for all samples, bnf and rnc fragments. If you require someone to do this, I will do it. I'm having trouble seeing the benefit here. They might work well in the HTML version, but I don't think they do in the text version. Could you show me an example where it would help the text version? Robert Sayre
Re: Obs on format-07
> - in 6.4; extension schema allow the use of the atom namespace as child > elements of the extension. I do not recall this being discussed, but > personally am +1 to it. Yeah, I'm ok with it too. I'm not sure why anyone would want to do it, but the spirit of Structured Extension elements was that (almost) anything goes. -- Dave
Re: Obs on format-07
Tim Bray wrote: On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote: Sam Ruby wrote: An additional observation: neither of the examples in section 1.1 include the summary element. Suggestion: change the "content" in the first (minimal) example to "summary". ""? No. --Tim Perhaps it would help if I was more clear. If you start with this: Some text. And you change content to summary, you end up with this: Some text. I happen to be of the opinion that in terms of linear spec space, these two examples with be the most cost effective portions of the spec. Most people, after seeing these, will have few questions and will only need to take seek out other sections if they have specific questions. Coupled with the existance of the feedvalidator, this isn't such a bad thing. I'd like such people to have been exposed to both summary and content elements. Used in a manner that most people would find helpful: i.e., non-empty. - Sam Ruby
Re: Obs on format-07
Sam Ruby wrote: Tim Bray wrote: On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote: ""? No. --Tim Some text. I've incorporated Sam's suggested wording. Robert Sayre
Re: Obs on format-07
Robert Sayre wrote: Bill de hÓra wrote: - I believe atomfeed and ...? I was going to say something about schematron - don't mind it. The spec will be clearer for leaving the schematron in. cheers Bill
Re: Obs on format-07
>> "Note: the following example is not well formed unless the XHTML >> namespace has been bound previously to the "xh" prefix in the >> document:" tangent: perhaps we could also insert a note along the lines of ... "Note: @type="XHTML" does not automatically imbue the contents of the atom:content element with the appropriate or necessary XML namespace." ... point being to alert XML ignorant to a possible problem. Certainly can be better worded. e.
Re: Obs on format-07
Bill de hÓra wrote: Hi editors, Comments and observations on the 07 draft. ** RNC Schema - is valid rnc - the schema and the fragments appear to be consistent. - both examples validate according to the supplied schema - the xhtml fragments in 4.1.3.4 validate when embedded as specified. - in 6.4; simple and extension schema forbid the use of the atom namespace as the top level element in the extension. This is a very common RNG idiom and I imagine the text should reflect the constraint assuming that's the consensus of the WG. Note that it cannot generally be represented in WXS; for example, Trang will convert it to a looser xsd:any constraint. - in 6.4; extension schema allow the use of the atom namespace as child elements of the extension. I do not recall this being discussed, but personally am +1 to it. - I believe atomfeed and ...? replace: [[[ App B Collected RELAX NG Compact Schema ]]] with: "App B RELAX NG Compact Schema" reason: not all the schema is presented in fragment form, so the title is incorrect. Correct. In 1.2, how about "A complete schema appears in Appendix B." ** 1. Introduction p2. the last sentence requires a for-example or should be struck. reason: qualify what 'other purposes' might be. > ** 1.1 Examples: Please use a namespace prefix for both or at least one of the examples. reason: 1) default namespaces are not robust (I offer requirement of xhtml:div as evidence), examples in XML formats should not propagate the practice. 2) example markup is not consistent with naming convention used to call out specified elements. Please add a element property to an entry that is not from the format (ie Dublin Core) reason: demonstrate what extensible indicates upfront. I am concerned that any extension element in the examples will create a procedural issue. I am also concerned that the target audience for a prefixed example would be rather small. ** 2. Atom Documents p5: this paragraph can be struck without loss of meaning. reason: adds no specification value. Agree. p8: replace: [[[ Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. For resolution, IRIs can easily be converted to URIs. When comparing IRIs serving as atom:id values, they MUST NOT be converted to URIs. By definition, every URI is an IRI, so any URI can be used where an IRI is needed. ]]] with the following: "Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. By definition, every URI is an IRI, so any URI can be used where an IRI is needed. Note: 1. For purposes of resolution, IRIs MAY be converted to URIs. 2. For purposes of comparison, where IRIs act as atom:id values, they MUST NOT be converted to URIs." Also, if 'resolution' is a term taken from some spec it should be called out as such. 'resolution' is a little sloppy. How about this: [[[ Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. IRIs can easily be converted to URIs, and every URI is an IRI, so any URI can be used where an IRI is needed.. When comparing IRIs serving as atom:id values, they MUST NOT be converted to URIs. By definition, ]]] reason: p8 does not read clearly enough to provide implementor guidance. ob: I think this indicates an implementor burden of using IRIs. I need to write conversion code differently depending on whether I'm resolving or comparing. Yes, but this is as specified by RFC3987, section 5.1, p4. p10: remove the following clause: [[[but may be defined by an extension to Atom.]]] reason: the caveat adds no specification value and provides questions without answers (does 'may' mean 'might' above? defined by who? etc). Agree. ** 3.1.1 The "type" Attribute replace: [[[ Note that MIME media types [RFC2045] are not acceptable values for the "type" attribute. ]]] with: "MIME media types [RFC2045] MUST NOT be used as values for the "type" attribute." reason: state the specification as specification not as a side note. Agree. ** 3.1.1.3 XHTML replace [[[ The following example assumes that the XHTML namespace has been bound to the "xh" prefix earlier in the document: ]]] with "Note: the following example is not well formed unless the XHTML namespace has been bound previously to the "xh" prefix in the document:" reason: clearly indicate what conformance prefix binding entails. Tim covered this. ** 4.1.1 The "atom:feed" Element replace: [[[ * atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. atom:feed elements MUST NOT contain more than one atom:author element. ]]] with: "* atom:feed elements MUST contain an atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. * atom:feed elements MUST NOT contain more than one atom:author element." reason: give each spec its own bullet point. Agree. replace: [[[ * atom:feed elements MUST NOT contain more than one atom:link element with a r
Re: Obs on format-07
On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote: Sam Ruby wrote: An additional observation: neither of the examples in section 1.1 include the summary element. Suggestion: change the "content" in the first (minimal) example to "summary". ""? No. --Tim
Re: Obs on format-07
Sam Ruby wrote: An additional observation: neither of the examples in section 1.1 include the summary element. Suggestion: change the "content" in the first (minimal) example to "summary". ""? Robert Sayre
Re: Obs on format-07
An additional observation: neither of the examples in section 1.1 include the summary element. Suggestion: change the "content" in the first (minimal) example to "summary". - Sam Ruby
Re: Obs on format-07
On Wednesday, April 6, 2005, at 07:50 PM, Bill de hÓra wrote: "Note: the following example is not well formed unless the XHTML namespace has been bound previously to the "xh" prefix in the document:" +1 to the concept, but perhaps it could be worded a little differently, eg. 'Note: the following example is only well formed if the XHTML namespace has been bound to the "xh" prefix earlier in the document.' If we want to be more verbose to be precise, we could add something to the effect that that namespace to prefix binding is in scope at this point in the document. Reasons: 1) the first part of the sentence sounds like it's going to say that we're about to show an invalid example, and 2) "previously" (or "earlier") and "in the document" belong together. Perhaps the editors would have tweaked it, but it doesn't hurt to comment... "* atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" which have the same type attribute value. Under atom:entry, we have: 'atom:entry elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same combination of type and hreflang attribute values.' hreflang needs to be added under feed too, right? 4.2.9.2 The "rel" Attribute, p1 and referred to in 3.3. It's incidental enough to be dropped. Not sure what you're referring to here. Could you quote the text?
Re: Obs on format-07
On Apr 6, 2005, at 6:50 PM, Bill de hÓra wrote: Hi editors, Comments and observations on the 07 draft. Most seem OK to me, but... replace [[[ The following example assumes that the XHTML namespace has been bound to the "xh" prefix earlier in the document: ]]] with "Note: the following example is not well formed unless In fact, it is "well-formed" if you are using that word in the technical XML sense; the definition of well-formedness does not forbid random colon prefixing. I think this is OK left as is. The meaning is entirely unambiguous. -Tim
Obs on format-07
Hi editors, Comments and observations on the 07 draft. ** RNC Schema - is valid rnc - the schema and the fragments appear to be consistent. - both examples validate according to the supplied schema - the xhtml fragments in 4.1.3.4 validate when embedded as specified. - in 6.4; simple and extension schema forbid the use of the atom namespace as the top level element in the extension. This is a very common RNG idiom and I imagine the text should reflect the constraint assuming that's the consensus of the WG. Note that it cannot generally be represented in WXS; for example, Trang will convert it to a looser xsd:any constraint. - in 6.4; extension schema allow the use of the atom namespace as child elements of the extension. I do not recall this being discussed, but personally am +1 to it. - I believe atomfeed and replace: [[[ App B Collected RELAX NG Compact Schema ]]] with: "App B RELAX NG Compact Schema" reason: not all the schema is presented in fragment form, so the title is incorrect. ** 1. Introduction p2. the last sentence requires a for-example or should be struck. reason: qualify what 'other purposes' might be. ** 1.1 Examples: Please use a namespace prefix for both or at least one of the examples. reason: 1) default namespaces are not robust (I offer requirement of xhtml:div as evidence), examples in XML formats should not propagate the practice. 2) example markup is not consistent with naming convention used to call out specified elements. Please add a element property to an entry that is not from the format (ie Dublin Core) reason: demonstrate what extensible indicates upfront. ** 2. Atom Documents p5: this paragraph can be struck without loss of meaning. reason: adds no specification value. p8: replace: [[[ Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. For resolution, IRIs can easily be converted to URIs. When comparing IRIs serving as atom:id values, they MUST NOT be converted to URIs. By definition, every URI is an IRI, so any URI can be used where an IRI is needed. ]]] with the following: "Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. By definition, every URI is an IRI, so any URI can be used where an IRI is needed. Note: 1. For purposes of resolution, IRIs MAY be converted to URIs. 2. For purposes of comparison, where IRIs act as atom:id values, they MUST NOT be converted to URIs." Also, if 'resolution' is a term taken from some spec it should be called out as such. reason: p8 does not read clearly enough to provide implementor guidance. ob: I think this indicates an implementor burden of using IRIs. I need to write conversion code differently depending on whether I'm resolving or comparing. p10: remove the following clause: [[[but may be defined by an extension to Atom.]]] reason: the caveat adds no specification value and provides questions without answers (does 'may' mean 'might' above? defined by who? etc). ** 3.1.1 The "type" Attribute replace: [[[ Note that MIME media types [RFC2045] are not acceptable values for the "type" attribute. ]]] with: "MIME media types [RFC2045] MUST NOT be used as values for the "type" attribute." reason: state the specification as specification not as a side note. ** 3.1.1.3 XHTML replace [[[ The following example assumes that the XHTML namespace has been bound to the "xh" prefix earlier in the document: ]]] with "Note: the following example is not well formed unless the XHTML namespace has been bound previously to the "xh" prefix in the document:" reason: clearly indicate what conformance prefix binding entails. ** 4.1.1 The "atom:feed" Element replace: [[[ * atom:feed elements MUST contain exactly one atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. atom:feed elements MUST NOT contain more than one atom:author element. ]]] with: "* atom:feed elements MUST contain an atom:author element, UNLESS all of the atom:feed element's child atom:entry elements contain an atom:author element. * atom:feed elements MUST NOT contain more than one atom:author element." reason: give each spec its own bullet point. replace: [[[ * atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same type attribute value. If a feed's atom:link element with type="alternate" resolves to an HTML document, then that document SHOULD have a autodiscovery link element [Atom-autodiscovery] that reflects back to the feed. atom:feed elements MAY contain additional atom:link elements beyond those described above. ]]] with: "* atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" which have the same type attribute value. * If a feed's atom:link element with type="alternate" resolves to an HTML document, then that document SHOULD have a autodiscovery link element [Atom-autodiscovery] that reflects back t
