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
Bill de hra 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
Robert Sayre wrote: Bill de hra 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: ... title type=html Less: lt;em amp;lt; lt;/em /title ... ]]] 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
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
Robert Sayre wrote: Bill de hra 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
Sam Ruby wrote: Tim Bray wrote: On Apr 6, 2005, at 8:09 PM, Robert Sayre wrote: summary/? No. --Tim summarySome text./summary I've incorporated Sam's suggested wording. 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
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 to the feed. * atom:feed
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
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
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
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. summary/? Robert Sayre
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. summary/? No. --Tim
