[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Feedback on 0.3 Format
Mark Nottingham has posted his thoughts on the latest
release of the Atom Format: http://www.mnot.net/blog/2003/12/12/notes_on_atom
The version attribute - I thought this was one of the
reasons we wanted to move on from RSS; numeric versions
are linear, are apt to have lots of things read into them,
and carry redundant information to the namespace. See the TAG finding.
I agree with the TAG finding, which says a verion attribute
is good practice:
Good Practice - Identify specific version with version attribute:
The specific version of a set of names within a given namespace
may be identified with a version attribute to differentiate
between the compatible versions
Adding extensions - There’s no way to identify whether an extension module
(e.g., in an entry) is required to understand the feed; this is our
one opportunity to put a mustUnderstand semantic into ATOM.
Why isn’t it there? Once again, see the TAG finding (DavidO did some fantastic work on this).
I agree that the Atom specification should include
a statement of the processing model, that is, what a client
should do with elements it does not understand.
I also find that I agree with the TAG Good Practice,
which is that clients take a "must ignore" stance,
and ignore elements they do not understand [1]:
Good Practive - Must Ignore: Receivers MUST ignore any XML
attributes or elements that they do not recognize in a valid XML document.
Good Practice - Must Ignore All: The Must Ignore
rule applies to unrecognized elements and their descendents.
The mode attribute - The list of possible values isn’t qualified;
is this a completely closed list that will never change? If
not, how does it get added to in the future? E.g., what if
someone comes up with a really nifty encoding that they want
to use for their application? I’d suggest using a URI rather than a token here.
I don't believe the list of modes should be closed. I also don't think
that there are going to me enough modes in circulation
to justify using a URI over a token here.
The rel attribute - Same as the mode attribute.
Again, just like mode, I don't believe the list of
values should be closed. I also don't think
that there are going to me enough 'rel's in circulation
to justify using a URI over a token here. Besides,
there is an already existing RFC on how to extend
the 'rel' values.
The type attribute - This is probably too radical for
some, but why not use a URI rather than a media type
here? You can identify media types with URIs
(e.g., urn:ietf:params:media-type:image/jpg), and you
can also identify more ad hoc formats (e.g., business-specific
ones) without the pain and uncertainty of media type registration.
Count me in with the 'some' group, that is,
I agree that this is too radical, I do not want to use
URIs for mime-types.
@mode="escaped" - It’s unclear what’s meant by ‘escaped’ here; is it XML? HTML? URI?
@mode="escaped" means that if you do a single level of
XML unescaping on the content value, then you will get
a string in the mime-type listed in @type.
When I say "a single level of XML unescaping" I
mean a single pass of turning < into <, > into >, etc.
-joe
[1] http://www.w3.org/2001/tag/doc/versioning.html#d0e706
--
http://BitWorking.org
http://WellFormedWeb.org