(CC'ing the list.)
* 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?
3.1 is Text Constructs, which are used for
inside the <head> element ... 4.2.1 "atom:title" Element 4.2.8 "atom:tagline" Element 4.2.11 "atom:copyright" Element 4.2.12 "atom:info" Element
inside the <entry> element ... 5.1 "atom:title" Element 5.11 "atom:summary" Element 5.13 "atom:copyright" Element
Which of these do you want to use MathML or SVG, and why can't you use @type="XHTML" with name spaced MathML/SVG inside that?
I can see usage of MathML in atom:enntry>atom:title and perhaps even in atom:head>atom:title. atom:tagline could include a little SVG image.
The problem is that the specification uses a SHOULD for validating XHTML. That is the problem.
Note that Text Constructs are not used for 5.12 "atom:content" Elements
I am aware of that although it not really clear from the specification.
* 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.
agree on the name clash. 3.5.2 should be "type", but 3.1.1 should be something else. "mode" maybe?
+1 for a MODE attribute.
* 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?
interesting thought -- how would that actually look, in practice?
"Content-Type:application/atom+xml;version=1.1" or so. This would make it easier for aggregators to see if they need to download the whole feed. It would also make content negotiation more interesting since aggregators can claim to support a specific version of Atom, not all of them.
* 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?
agree. I've mentioned this on list a few times, I think we need a Pace to get anyone to notice.
A pace is a wiki document which proposes new wording to be included in the next specification?
* 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's a Service Construct, as detailed in 3.4, and 3.4.1. does say "whose value MUST be a URI reference"
Maybe the editor should insert "(see section 3.4)" after any reference of "Service Construct" (and similarly for any other mentions of the various constructs).
That would certainly be more useful and make the specification easier to read.
* 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.
agreed again. The insanity of it all was that there were some combinations of MODE and TYPE which were nonsensical, which is a completely bogus reason.
This would need a pace as well, I assume?
* 5.12.2 "src" attribute
How about fallback content?
zero or one <content> elements allowed, which is disappointing since we can't even have alternates in different languages.
Too bad. I was thinking of something as in:
<content src="foo">foo</content>
This would basically make it act the same as the OBJECT element in HTML. It probably would require a SRCTYPE attribute.
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?
Yes. That's what that paragraph means.
Then I am in the opinion that paragraph should be changed. AFAIK SVG documents (and perhaps other XML formats that you do not really want to embed directly) can get pretty large.
-- Anne van Kesteren <http://annevankesteren.nl/>
