Subject: Re: Issues with draft-ietf-atompub-format-04

From: Anne van Kesteren <[email-masked]>
Date: Tue, 25 Jan 2005 13:45:37 +0100

(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/>