Anne van Kesteren wrote:
* 3.1.1 "type" Attribute
I was wondering how I can include MathML in Atom posts or simple SVG fragments. If there are extension mechanisms available, shouldn't 3.1.1 refer to those?
You can put it in atom:content. Other core elements are there to provide a *baseline*.
* 3.5.1 "rel" Attribute
Why are the only values defined "alternate" and "related"? I have implemented "via" for a long time on my personal weblog and some aggregators have even implemented support for it. I consider it to be quite useful.
Write a Pace. I would support it.
* 3.5.2 "type" Attribute
It is a bit vague that this TYPE attribute differs from the one in section 3.1.1. Where this one MUST have a MIME type as value the other MUST NOT.
This is incorrect.
* 3.5.4 "hreflang" Attribute
What I do not understand is that Atom provides a mechanism for linking to translations of the entry but does not provide a mechanism to include the actual translation. (For example, by allowing only a single TITLE element instead of allowing multiple if the value of the xml:lang attribute is different.)
People are not born with Atom documents in their hands. We don't need to provide for every eventuality.
* 4.1 "version" Attribute
Does this attribute imply the feed has to be downloaded first before the
aggregator knows if it supports the Atom format used? Can this not be
solved by a MIME type parameter or is that going to difficult to implement?
I think "version" should be dropped. We can always add it later.
* 4.2.2 "atom:link" Element
It does not make sense to only allow a single "alternate" link construct if the TYPE attribute has the same value. What if I have translations of the document in question? For example:
# <link rel="alternate" type="text/html" hreflang="nl" href="/nl/"/> # <link rel="alternate" type="text/html" hreflang="ja" href="/ja/"/>
I agree. I think we should allow one or more.
* 5.4 "atom:edit" Element
Why does the specification not define that this MUST be a URI and how this URI MUST be processed as is done in for example 3.5.3?
It does. See "Service Construct".
* 5.8 "atom:id" Element
What type of content does this element contain? A URI, a string? How should it be created? How can I make sure, as a publisher that my atom:id value is universally unique and always will be?
See "Identity Construct".
* 5.12.1 "type" attribute
This makes the TYPE attribute suck even more, IMHO. Can the Atom WG not
introduce a second attribute? I believe we had MODE and TYPE some time ago.
Co-constraints suck. @mode would be a multiplier on the ones we already have.
* 5.12.2 "src" attribute
How about fallback content? What is meant with "should be local"? For example, what do I do if I want to include a large SVG graphic in my feed which has the MIME type "image/svg+xml". Should I include it into the feed?
You have lots of options that don't require "fallback content". We rejected xhtml:object a long time ago.
Robert Sayre
