[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-nottingham-atom-format-02


Thanks for the feedback, Henri. I respond to what feel like the editorial issues below.

On Dec 13, 2003, at 3:24 AM, Henri Sivonen wrote:

The spec talks mainly about elements which are in the Atom namespace. Is the use of the prefix in the prose necessary? The use of a particular prefix creates an illusion that the prefix is significant (even though the prose states it isn't).

It's more precise, and enforces the ides that namespaces are central to the format. This is becoming common practice in specifying namespace-aware formats, and I think it's a good thing.

Atom documents MAY contain Comments wherever they are legal in XML.

In order to discourage bogus use of comments, I suggest this wording: "[XML 1.0] allows comments is XML documents but does not require XML processors to make comments available to the application. Therefore, Atom producers MAY include comments where allowed by [XML 1.0] but MUST NOT use comments to transfer data intended for processing by Atom consumers."

I like the sentiment, but the language restates the requirements of XML, so I'd prefer them not to be RFC2119 requirements, just explanatory text.

All elements and attributes in an Atom document MUST be
namespace-qualified. Note that this requirement does not preclude the
use of a default namespace.

The first syntax example contains attributes which aren't in a namespace. That's why I suggested in an earlier message that the spec include something like this: "Attributes which are in no namespace and attributes which are in the Atom namespace MUST be treated equivalently (according to the meaning given in this specification) when the attributes appear on an element which is in the Atom namespace."

Nice catch. This is one approach to the problem; we could also just say that the attributes defined by this spec (are | are not) in a namespace (I'm a little wary of requiring both forms to be understood, because it forces implementations to check for both).

"escaped": A mode attribute with the value "escaped" indicates that
the element's content is an escaped string. Processors MUST
unescape the element's content before considering it as content of
the indicated media type.

An attempt at an alternative (hopefully more precise) wording:
"escaped": A mode attribute with the value "escaped" indicates that the element's content is a string. Note: The value "escaped" is due to [XML 1.0] requiring markup-significant characters to be escaped in character data. The XML processor will do the required unescaping on behalf of an Atom consumer application. The mode "escaped" is only suitable for transferring media types that are defined in terms of characters and can be represented as a sequence of characters allowed in [XML 1.0].

This is better.

"base64": A mode attribute with the value "base64" indicates that
the element's content is base64-encoded [RFC2045]. Processors MUST
decode the element's content before considering it as content of
the the indicated media type.

"base64": A mode attribute with the value "base64" indicates that the element's logical content is a byte sequence and the byte sequence has been encoded using the base64 encoding [RFC2045] for transfer as XML character data. Atom consumers MUST decode the element's content before considering it as content of the indicated media type.

Yes.


The content of an atom:modified element SHOULD have a time zone whose
value MUST be "UTC".

Shouldn't that be "Z"?

Right now we refer to W3C datetime, which requires a time zone. If we retain the ability to omit the
time zone, we'll need to refer to either ISO8601, which brings its own set of problems (availability of the spec, size of the spec, etc.) or the XML Schema dateTime type.

This is a roundabout way of saying that the format of dates is in flux.