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

From: Anne van Kesteren <[email-masked]>
Date: Tue, 25 Jan 2005 09:59:08 +0100

* 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.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.

* 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.

* 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.)

* 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?

* 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/"/>

* 5.2 "atom:link" Element

This element has the same stupid restriction. It actually contradicts
the statement made in 3.5.4.

* 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?

* 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?

* 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.

* 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?

This was about it. I hope it is of some use.

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 25 Jan 2005 17:57:16 +0100

> This was about it. I hope it is of some use.

I share all your concerns and issues and hope they will be addressed  
properly before the format is finalized.

-- 
Asbjørn Ulsberg     -=|=-    http://virtuelvis.com/quark/
«He's a loathsome offensive brute, yet I can't look away»

---

From: Robert Sayre <[email-masked]>
Date: Tue, 25 Jan 2005 19:03:16 -0500

> fragments. If there are extension mechanisms available, shouldn't 3.1.1

You can put it in atom:content. Other core elements are there to provide 
a *baseline*.

> aggregators have even implemented support for it. I consider it to be

Write a Pace. I would support it.

> section 3.1.1. Where this one MUST have a MIME type as value the other

This is incorrect.

> element instead of allowing multiple if the value of the xml:lang

People are not born with Atom documents in their hands. We don't need to 
provide for every eventuality.

> solved by a MIME type parameter or is that going to difficult to 

I think "version" should be dropped. We can always add it later.

> # <link rel="alternate" type="text/html" hreflang="ja" href="/ja/"/>

I agree. I think we should allow one or more.

> this URI MUST be processed as is done in for example 3.5.3?

It does. See "Service Construct".

> atom:id value is universally unique and always will be?

See "Identity Construct".

> introduce a second attribute? I believe we had MODE and TYPE some time 

Co-constraints suck. @mode would be a multiplier on the ones we already 
have.

> feed which has the MIME type "image/svg+xml". Should I include it into

You have lots of options that don't require "fallback content". We 
rejected xhtml:object a long time ago.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Wed, 26 Jan 2005 21:40:01 -0500

> Write a Pace. I would support it.

Yes, please.

- Sam Ruby

---

From: Anne van Kesteren <[email-masked]>
Date: Thu, 27 Jan 2005 21:29:55 +0100

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.

>> aggregators have even implemented support for it. I consider it to
>> be quite useful.
>

Ok. I'll try to create one.

>> 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.

>> 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.

>> 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?
>

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.

>> 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:
>

Does this change require or pace or is this enough?

>> 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?
> 

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?
>

Same as above. Plus, you did not answer my second question.

>> 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?
>

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.

---

From: Robert Sayre <[email-masked]>
Date: Thu, 27 Jan 2005 15:39:04 -0500

Anne van Kesteren wrote:

>
> So I can not include MathML in the TITLE of my weblog? I do not see 
> why this restriction is necessary.

Nope. Can any aggregator display it? I wonder if Shrook users are 
filling Graham's inbox with requests for MathML in their titles.

> 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.

There are lots of different languages in America, too!

> address something like feed language negotiation in the specification.

If what you say is true, then aggregators don't support multiple 
alternatives at all right now. Content Negotiation is covered by RFC2616.

> not reject new feeds. They will just found out they can not parse them 

The namespace will change.

> Does this change require or pace or is this enough?

I don't know.

> Can this be referenced from within the specification? As in "See 
> section ..."

Sure.

Robert Sayre

---

From: Henri Sivonen <[email-masked]>
Date: Fri, 28 Jan 2005 08:06:40 +0200

On Jan 27, 2005, at 22:39, Robert Sayre wrote:

> Nope. Can any aggregator display it?

I expect Gecko-based aggregators to support MathML eventually. After 
all, once you support XHTML content in a Gecko-based aggregator in a 
non-bogotic way (XML DOM to XML DOM copy with platupus filtering), you 
get MathML for free.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Robert Sayre <[email-masked]>
Date: Fri, 28 Jan 2005 01:24:12 -0500

> non-bogotic way (XML DOM to XML DOM copy with platupus filtering), you 

We are not here to standardize "eventually."

This discussion is a waste of time.

Robert Sayre

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 30 Jan 2005 18:06:03 +0100

> filling Graham's inbox with requests for MathML in their titles.

Addressed in a separate thread.

>> sense to provide a feed based on language negotiation since feed aggregators do not support that.
> 

I thought the only official language was en-US?

> alternatives at all right now. Content Negotiation is covered by RFC2616.

I believe most support content negotiation. However, I do not believe 
they send out an Accept-Language header.

> The namespace will change.

Only for the elements that are changed?

---

From: Henri Sivonen <[email-masked]>
Date: Sun, 30 Jan 2005 22:06:23 +0200

>>> aggregators do not support that.

So how many European sites besides the EU have the resources to provide 
translations of the *same* content in multiple languages at the same 
time? How many of those can't provide multiple feed links and really 
want to stuff everything in a single feed?

Aren't language alternatives within a feed over-engineering.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/

---

From: Walter Underwood <[email-masked]>
Date: Sun, 30 Jan 2005 14:52:06 -0800

--On January 30, 2005 10:06:23 PM +0200 Henri Sivonen <[email-masked]> wrote:
> translations of the *same* content in multiple languages at the same time?

Pretty common in Quebec. We see English and Spanish in the US from Texas
to California. California has voter guides in seven languages. It isn't
limited to goverments, UBS's site is in four languages and the San Jose
Mercury New has editions in Spanish and Vietnamese.

> How many of those can't provide multiple feed links and really want to stuff
> everything in a single feed?

Good question. The answer probably depends on how much client software
allows you to select a preferred locale. All browsers do, so they could
easily do that with Atom feeds.

Locales aren't just language. You could offer English in US, UK, and
Australian versions. I was completely mystified about what the Aussies
might mean by "footy tipping".

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Graham <[email-masked]>
Date: Sun, 30 Jan 2005 23:55:17 +0000

On 30 Jan 2005, at 8:06 pm, Henri Sivonen wrote:

> So how many European sites besides the EU have the resources to 
> provide translations of the *same* content in multiple languages at 
> the same time? How many of those can't provide multiple feed links and 
> really want to stuff everything in a single feed?
>

I'm going to agree with Henry here. Sites will have separate feeds for 
separate languages. No one will use this feature (publishers won't 
trust software at the far end to support it, users will want absolute 
control), and it requires a lot of new stuff in the client, and 
intermediaries, to select which language to use.

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 31 Jan 2005 02:11:52 +0100

On Sun, 30 Jan 2005 22:06:23 +0200, Henri Sivonen <[email-masked]> wrote:

> time?

The company I work in (the Norwegian Broadcasting Company), for instance.  
And most definately the BBC. And many other broadcasters, including RN  
(Radio Netherlands) which broadcasts and publishes content in many  
different languages. Don't any Finish broadcasters publish or broadcast  
content in both Finish and Sami for instance?

> How many of those can't provide multiple feed links and really want to
> stuff everything in a single feed?

All of the above, I'd presume. If it can be stuffed into the same feed,  
everyone would of course rather do that than create separate documents for  
each language.

> Aren't language alternatives within a feed over-engineering.

No, not at all. It makes it possible to do for those who want, but don't  
have any implications on other producers.

---

From: Henri Sivonen <[email-masked]>
Date: Mon, 31 Jan 2005 09:39:46 +0200

On Jan 31, 2005, at 03:11, Asbjørn Ulsberg wrote:

>> the same time?
> The company I work in (the Norwegian Broadcasting Company), for 
> instance. And most definately the BBC. And many other broadcasters, 
> including RN (Radio Netherlands) which broadcasts and publishes 
> content in many different languages. Don't any Finish broadcasters 
> publish or broadcast content in both Finish and Sami for instance?

There are TV programs in Swedish, but they are not translations of 
Finnish content. Both the Finnish and Swedish branches have news, but 
they have separate editorial processes. I expect the Sami radio to have 
separate editorial staff as well so that their content is not a mere 
translation of the content any Finnish-language channel.

> All of the above, I'd presume. If it can be stuffed into the same 
> feed, everyone would of course rather do that than create separate 
> documents for each language.

Why? The feed takes longer to download that way and you pay more for 
bandwidth.

> No, not at all. It makes it possible to do for those who want, but 
> don't have any implications on other producers.

All features involve a cost at the consumer side.

-- 
Henri Sivonen
[email-masked]
http://iki.fi/hsivonen/