Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
Thanks for the feedback, Robert... Robert Sayre wrote: - rel attribute is missing The rel attribute is optional and the relation is considered to be alternate in that case. http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.2.p.4: 'atom:head elements MUST contain at least one atom:link element with a rel attribute value of alternate.' 05-C05, 4.15.3 processing model http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.3 If the value of type ends with +xml or /xml, the content of atom:content may include child elements, and SHOULD be suitable for handling by software that knows the indicated media type. If the src attribute is not provided, this would normally mean that the atom:content element would contain a single child element which would serve as the root element of the XML document of the indicated type. The statement about the src attribute seems to be unnecessary given the SHOULD-level requirement to have local content (thus no src attribute). If the value of type begins with text/ the content of atom:content MUST NOT contain child elements. See 4.15.2: so is this a SHOULD or a MUST? It's a MUST, and not an editorial change. If it's a MUST then http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.2.p.3 needs to be adjusted. I think this should come with the following URL: http://www.oasis-open.org/committees/relax-ng/spec-20011203.html I don't want to refer to OASIS's URLs. Why not? Aren't they considered to be stable? Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
Sam Ruby wrote: Julian Reschke wrote: atomTitle type=XHTML xmlns:xhtml=http://www.w3.org/1999/xhtml; Less: xhtml:em lt; /xhtml:em /atomTitle (hope I got these right). This is not only right, but also a good example of why many people would prefer to have another element so that they don't have to deal with prefixes: atomTitle type=XHTML div xmlns=http://www.w3.org/1999/xhtml;Less: em lt; /em/div /atomTitle The above is similar to your example, but not _identical_ to your example, given the current spec. Well, the current spec absolutely allows people to stick in the div element. It just doesn't require them to do it. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
Julian Reschke wrote: Thanks for the feedback, Robert... Robert Sayre wrote: - rel attribute is missing The rel attribute is optional and the relation is considered to be alternate in that case. http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.2.p.4: 'atom:head elements MUST contain at least one atom:link element with a rel attribute value of alternate.' Point taken. How about 'atom:head elements MUST contain at least one atom:link element with a relation of alternate.' 05-C05, 4.15.3 processing model If the value of type begins with text/ the content of atom:content MUST NOT contain child elements. See 4.15.2: so is this a SHOULD or a MUST? It's a MUST, and not an editorial change. If it's a MUST then http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.2.p.3 needs to be adjusted. You're correct, but the WG should decide which sentence will change. I think this should come with the following URL: http://www.oasis-open.org/committees/relax-ng/spec-20011203.html I don't want to refer to OASIS's URLs. Why not? Aren't they considered to be stable? I couldn't find any standards track documents that reference them. I guess we could link it up in the HTML document, but note that the W3C docs are linked either. Robert Sayre
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
Robert Sayre wrote: 'atom:head elements MUST contain at least one atom:link element with a rel attribute value of alternate.' Point taken. How about 'atom:head elements MUST contain at least one atom:link element with a relation of alternate.' Can't we just get rid of the defaulting? That would make the spec simpler with little additional verbosity in the instance documents. I think this should come with the following URL: http://www.oasis-open.org/committees/relax-ng/spec-20011203.html I don't want to refer to OASIS's URLs. Why not? Aren't they considered to be stable? I couldn't find any standards track documents that reference them. I guess we could link it up in the HTML document, but note that the W3C docs are linked either. For instance http://www.w3.org/TR/xhtml2/references.html#ref_RELAXNG and http://greenbytes.de/tech/webdav/rfc3470.html#RELAX-NG. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
On Jan 31, 2005, at 4:37 AM, Robert Sayre wrote: 05-C05, 4.15.3 processing model If the value of type begins with text/ the content of atom:content MUST NOT contain child elements. See 4.15.2: so is this a SHOULD or a MUST? It's a MUST, and not an editorial change. If it's a MUST then http://atompub.org/2005/01/27/draft-ietf-atompub-format -05.html#rfc.section.4.15.2.p.3 needs to be adjusted. You're correct, but the WG should decide which sentence will change. Huh? What's the issue? I just stared at that text for a couple of minutes and didn't get it. -Tim
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
Tim Bray wrote: On Jan 31, 2005, at 4:37 AM, Robert Sayre wrote: 05-C05, 4.15.3 processing model If the value of type begins with text/ the content of atom:content MUST NOT contain child elements. See 4.15.2: so is this a SHOULD or a MUST? It's a MUST, and not an editorial change. If it's a MUST then http://atompub.org/2005/01/27/draft-ietf-atompub-format -05.html#rfc.section.4.15.2.p.3 needs to be adjusted. You're correct, but the WG should decide which sentence will change. Huh? What's the issue? I just stared at that text for a couple of minutes and didn't get it. -Tim As far as I understand the spec, 4.15.2 (last sentence) says it's a SHOULD, 4.15.3 (5.) says it's a MUST. I think the fact that both sections say something about the same thing is the problem that needs to be fixed. Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
Hi, first I'd like to thank the editors for the good work. The issues were collected after reading the spec top-to-bottom, and trying to produce an Atom-05 feed from an existing RSS-1.0 feed through XSLT. Most of them are editorial. Best regards, Julian -- snip -- 05-C01, 1.2 Example http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.1.2 Inconsistencies: - version attribute (whitespace) - rel attribute is missing 05-C02, 3.1.1, type attribute http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1 Suggested examples for TEXT, HTML and XHTML: a title containing the string Less: , where the less sign displays emphasized when possible.. atomTitle type=TEXT Less: lt; /atomTitle atomTitle type=HTML Less: lt;em amp;lt; lt;/em /atomTitle atomTitle type=XHTML xmlns:xhtml=http://www.w3.org/1999/xhtml; Less: xhtml:em lt; /xhtml:em /atomTitle (hope I got these right). 05-C03, 3.1.1, type attribute http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1 The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element. Add reference to XHTML1 (http://www.w3.org/TR/2002/REC-xhtml1-20020801), section A). 05-C03, 4.3, atom:head http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.3 'The version identifier for this specification is draft-ietf-atompub-format-05: do not deploy' Spelling of the version attribute inconsistent with section 4.1.1. 05-C04, 4.11 atom:host http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.11 Like others, I'm not sure I understand what this is for. I think one sentence of rational would make the spec easier to absorb. 05-C04, 4.15.2 atom:content http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.2 Like others, I find the syntactic impact of allowing it either to be in-line or out-of-band confusing. I don't feel strongly about this, but using two distinct XML elements instead might make things easier. If the value of type begins with text/ or ends with +xml, the content SHOULD be local; that is to say, no src attribute should be provided. I'm not sure I understand what this is for. It seems to discourage putting XML data out-of-band. Why? 05-C05, 4.15.3 processing model http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.15.3 If the value of type ends with +xml or /xml, the content of atom:content may include child elements, and SHOULD be suitable for handling by software that knows the indicated media type. If the src attribute is not provided, this would normally mean that the atom:content element would contain a single child element which would serve as the root element of the XML document of the indicated type. The statement about the src attribute seems to be unnecessary given the SHOULD-level requirement to have local content (thus no src attribute). If the value of type begins with text/ the content of atom:content MUST NOT contain child elements. See 4.15.2: so is this a SHOULD or a MUST? 05-C06, B RelaxNG schema http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.B I tried to use the schema to validate a feed that I generated and had the following problems: - my version of trang (20030619) didn't accept the Schematron rules -- what else do I need to use RNC as reprinted? - the namespace name doesn't match the current one 05-E01, todos For instance: http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.1.p.4 Recommend to do them using rfc2629bis's cref element. 05-E02, Notational Conventions http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#W3C.REC-xml-infoset-20011024 Should't we refer to http://www.w3.org/TR/2004/REC-xml-infoset-20040204/? http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#RELAX-NG I think this should come with the following URL: http://www.oasis-open.org/committees/relax-ng/spec-20011203.html 05-E03, Notational Conventions A collected schema appears in an informative appendix. (refer directly by section/appendix number). Same for some other intra-document references. 05-E04, Atom Documents ... relative reference [RFC2396bis] present in an Atom... RFC2396bis has been published as RFC3986. 05-E05, 3.2.2 atom:uri The content of atom:uri in a Person construct MUST be a URI reference [RFC2396bis]. Directly point to RFC3986's section (here: 4.1). 05-E06, 3.2.3 atom:email Its content MUST be an e-mail address [RFC2822]. Again, please refer directly to the definition. In this case, it seems to be section 3.4.1 (addr-spec production). 05-E07, 4.2 atom:head http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.4.2 The atom:head element MAY contain any namespace-qualified [W3C.REC-xml-names-19990114] elements as children. I think we're overdoing it here a bit and loose readability. I suggest to remove the
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
On Jan 30, 2005, at 12:21 PM, Julian Reschke wrote: The issues were collected after reading the spec top-to-bottom, and trying to produce an Atom-05 feed from an existing RSS-1.0 feed through XSLT. Most of them are editorial. Good stuff, Julian. If the value of type begins with text/ or ends with +xml, the content SHOULD be local; that is to say, no src attribute should be provided. I'm not sure I understand what this is for. It seems to discourage putting XML data out-of-band. Why? It does. The idea is that textual content is more valuable if it's right there in the feed than if you have to go elsewhere to get it. -Tim
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
Tim Bray wrote: On Jan 30, 2005, at 12:21 PM, Julian Reschke wrote: The issues were collected after reading the spec top-to-bottom, and trying to produce an Atom-05 feed from an existing RSS-1.0 feed through XSLT. Most of them are editorial. Good stuff, Julian. Thanks. If the value of type begins with text/ or ends with +xml, the content SHOULD be local; that is to say, no src attribute should be provided. I'm not sure I understand what this is for. It seems to discourage putting XML data out-of-band. Why? It does. The idea is that textual content is more valuable if it's right there in the feed than if you have to go elsewhere to get it. -Tim I agree that this is the case, but does that require a SHOULD-level requirement? Explaining the issue instead of just trying to enforce it may lead to better results... Best regards, Julian -- green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Re: Comments on draft 05, was: I-D ACTION:draft-ietf-atompub-format-05.txt
Julian Reschke wrote: atomTitle type=XHTML xmlns:xhtml=http://www.w3.org/1999/xhtml; Less: xhtml:em lt; /xhtml:em /atomTitle (hope I got these right). This is not only right, but also a good example of why many people would prefer to have another element so that they don't have to deal with prefixes: atomTitle type=XHTML div xmlns=http://www.w3.org/1999/xhtml;Less: em lt; /em/div /atomTitle The above is similar to your example, but not _identical_ to your example, given the current spec. - Sam Ruby
Re: I-D ACTION:draft-ietf-atompub-format-05.txt
On 28 Jan 2005, at 15:14, Danny Ayers wrote: On Thu, 27 Jan 2005 16:10:06 -0500, Robert Sayre [EMAIL PROTECTED] wrote: http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.txt Thanks Robert. The Relax NG snippets make a *huge* difference to the clarity. (Thanks Norm!). Yes. A real pleasure to read now :-)
I-D ACTION:draft-ietf-atompub-format-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Atom Publishing Format and Protocol Working Group of the IETF. Title : The Atom Syndication Format Author(s) : M. Nottingham, R. Sayre Filename: draft-ietf-atompub-format-05.txt Pages : 37 Date: 2005-1-27 This document specifies Atom, an XML-based Web content and metadata syndication format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-05.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-ietf-atompub-format-05.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-ietf-atompub-format-05.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-atompub-format-05.txt
