Robert Sayre 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*.
So I can not include MathML in the TITLE of my weblog? I do not see why this restriction is necessary.
* 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.
Ok. I'll try to create one.
* 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.
I saw you rectified that statement in another e-mail.
* 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.
In Europe there are lots of different languages. It does not make sense to provide a feed based on language negotiation since feed aggregators do not support that.
Either Atom should provide support for multiple languages or we should address something like feed language negotiation in the specification.
* 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.
True. But that does not help current aggregators. At least, they will not reject new feeds. They will just found out they can not parse them at some point.
* 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:
I agree. I think we should allow one or more.
Does this change require or pace or is this enough?
* 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".
Can this be referenced from within the specification? As in "See section ..."
* 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".
Same as above. Plus, you did not answer my second question.
* 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.
Two definitions as attribute value suck more IMHO. Especially since TYPE can cause confusion with html:type since we have adopted more from HTML. (Like the LINK element, several attributes.)
* 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.
This again, only answers the first question. By the way, I guess I could just do:
<content type="XHTML"> <div xmlns="http://www.w3.org/1999/xhtml";> <object data="foo" type="bar"> buz </object> </div> </content
To work around your limitation, can't I?
This construct does not really make sense IMHO.
-- Anne van Kesteren <http://annevankesteren.nl/>
