Subject: Questions about -04

From: Norman Walsh <[email-masked]>
Date: Wed, 12 Jan 2005 07:32:02 -0500

1. Is xml:base processing applied to the schema attribute of a Category
   Construct?

2. Why MUST a feed point to an alternate version. What if the feed is all
   I publish?

3. 4.2.2 says

   atom:head elements MUST NOT contain more than one atom:link element
   with a rel attribute value of "alternate" that has the same type
   attribute value.

   What if the atom:link elments have different hreflang values?

4. 5.14 says

   If an atom:entry is copied into one feed from another feed, then the
   atom:head element of the source feed SHOULD be inserted into the
   atom:entry unless the entry, as copied, already contains an atom:head...

   This suggests that atom:head is sometimes a child of atom:entry,
   but that doesn't seem to be allowed. Did I miss something?
   Or is it supposed to say that the contents of the head are
   copied into the entry?

5. 7.1 says

   Processing [W3C.REC-xmldsig-core-20020212].  Other XML signature
   mechanisms MUST NOT be used on the document element of an Atom
   document.

   Are we sure we want to prohibit them? How about making this a SHOULD
   and pointing out that processors are not required to recognize any
   mechanisms except XML DSig? Other mechanisms will be developed.
   Some of them may become widely deployed. Do we really want to force
   authors to generate non-conformant feeds when they decide to use
   them?

   I feel the same way about XML 1.1, fwiw, but I expect I'd lose that
   fight, so I'll just mention it in passing.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | It is as easy for the strong man to be
http://nwalsh.com/            | strong, as it is for the weak to be
                              | weak.-- Emerson

---

From: Norman Walsh <[email-masked]>
Date: Wed, 12 Jan 2005 08:40:44 -0500

/ Norman Walsh <[email-masked]> was heard to say:
| 4. 5.14 says
|
|    If an atom:entry is copied into one feed from another feed, then the
|    atom:head element of the source feed SHOULD be inserted into the
|    atom:entry unless the entry, as copied, already contains an atom:head...
|
|    This suggests that atom:head is sometimes a child of atom:entry,
|    but that doesn't seem to be allowed. Did I miss something?
|    Or is it supposed to say that the contents of the head are
|    copied into the entry?

Nevermind. I missed the title of 5.14, I guess. <blush/>

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Everything should be made as simple as
http://nwalsh.com/            | possible, but no simpler.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 12 Jan 2005 11:57:44 -0500

>1. Is xml:base processing applied to the schema attribute of a Category

It's a URI, rather a URI reference. From 2396bis:

"URI-reference = URI / relative-ref"

I guess this means we should put the "no relative references" language 
here as well.

>2. Why MUST a feed point to an alternate version. What if the feed is all

I don't know. I say we drop it.

>   What if the atom:link elments have different hreflang values?

Or, for that matter, different titles and URIs. I think we should drop 
the restriction.

>   Are we sure we want to prohibit them?
>  
>

I think we should drop that sentence.

Robert Sayre

---

From: Tim Bray <[email-masked]>
Date: Wed, 12 Jan 2005 09:36:58 -0800

> Or, for that matter, different titles and URIs. I think we should drop 

Any time you drop a restriction, you're adding complexity to 
implementations.  Might be worthwhile, but should be born in mind. -Tim

---

From: Antone Roundy <[email-masked]>
Date: Wed, 12 Jan 2005 11:27:46 -0700

> Or, for that matter, different titles and URIs. I think we should drop 

type: The reason for allowing multiple alternate links of different 
typs is obvious enough: you might have an HTML version, an Atom version 
(the current feed), an RSS 1.0 version, an RSS 2.0 version, a PDF 
version, etc.  The client could decide which link to render (and could 
render more than one) based on its own processing capabilities, and 
perhaps a user preference.  No restriction.

hreflang: Again, obvious: an English version, a Spanish version, a 
Japanese version, etc.  The client could decide which to render based 
on the user's language preference.  Drop the restriction.

title: What use would there be for this?  If you just can't decide 
which of two titles to give your webpage???  And what would a client do 
with it?  Choose one at random?  Render both--two links identical 
except for their title?  No benefit, plenty of detriment.  Keep the 
restriction.

uri: An argument could be made for this one.  For example, you might 
have two HTML versions: one using frames, and one that doesn't; one for 
broadband connections, one for dialup, etc.  The client would have to 
render them all, or pick one essentially randomly (eg., the first one), 
but at least there's a reason for it.  I wouldn't oppose dropping the 
restriction here.

---

From: Bill de hÓra <[email-masked]>
Date: Wed, 12 Jan 2005 18:28:22 +0000

> I don't know. I say we drop it.

+1.

> Or, for that matter, different titles and URIs. I think we should drop 

I'm not sure dropping the restriction fixes anything. I think your 
concerns indicate a latent problem with the link construct (no news 
there I guess); Methinks @rel is co-occurent and meta-markup at the same 
time, ie the value in @rel seems to want to scope over and constrain the 
possible other attribute values in its atom:link - and in  other sibling 
atom:link elements for that matter.   I say wait a bit before deciding.

> I think we should drop that sentence.

+1.

cheers
Bill

---

From: Sam Ruby <[email-masked]>
Date: Wed, 12 Jan 2005 16:54:27 -0500

> 2. Why MUST a feed point to an alternate version. What if the feed is all

Deja vu:

http://www.imc.org/atom-syntax/mail-archive/msg08836.html

I'm -1 on removing this restriction.

- Sam Ruby

---

From: Graham <[email-masked]>
Date: Wed, 12 Jan 2005 22:12:07 +0000

> I'm -1 on removing this restriction.

I'm +1 on removing it, and given the number of people who've commented 
on it over the last year, I think you're outnumbered.

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 12 Jan 2005 23:41:56 +0100

On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby <[email-masked]>  
wrote:

>> 2. Why MUST a feed point to an alternate version. What if the feed is  
>> all I publish?
>
> Deja vu:
>

I think this goes along with the alternate entry discussion which ended up  
in these paces:

<url: http://www.intertwingly.net/wiki/pie/PaceContentOrLink>
<url: http://www.intertwingly.net/wiki/pie/PaceOptionalAlternateLink>

> I'm -1 on removing this restriction.

I think alternate links for both entries and feeds should be optional, but  
I'm more eager to have it be optional for entries.

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

---

From: Sam Ruby <[email-masked]>
Date: Wed, 12 Jan 2005 18:53:20 -0500

Graham wrote:

>>> all

Every piece of running code, for all versions of RSS and Atom, expect 
this data to be present.

- Sam Ruby

---

From: Antone Roundy <[email-masked]>
Date: Wed, 12 Jan 2005 17:03:40 -0700

On Wednesday, January 12, 2005, at 04:53  PM, Sam Ruby wrote:
>> I'm +1 on removing it, and given the number of people who've 
>> commented on it over the last year, I think you're outnumbered.
>
...except CaRP and Grouper.  Any others?

---

From: Graham <[email-masked]>
Date: Thu, 13 Jan 2005 00:48:44 +0000

> ...except CaRP and Grouper.  Any others?

Shrook and NetNewsWire?

I believe Sam needs to go sit in the corner until he's learnt his 
lesson. Bad Sam.

Graham

---

From: Graham <[email-masked]>
Date: Thu, 13 Jan 2005 02:42:49 +0000

On 13 Jan 2005, at 2:39 am, Sam Ruby wrote:

> Every version of RSS has this as a mandatory element.  Every last one 
> of them.

Except RSS 2.0:
"An item may also be complete in itself, if so, the description 
contains the text (entity-encoded HTML is allowed; see examples), and 
the link and title may be omitted"

Graham

---

From: Sam Ruby <[email-masked]>
Date: Wed, 12 Jan 2005 21:39:04 -0500

> I believe Sam needs to go sit in the corner until he's learnt his 

Every version of RSS has this as a mandatory element.  Every last one of 
them.

- Sam Ruby

---

From: Sam Ruby <[email-masked]>
Date: Wed, 12 Jan 2005 21:56:19 -0500

Graham wrote:

> "An item may also be complete in itself, if so, the description contains 
> the text (entity-encoded HTML is allowed; see examples), and the link 
> and title may be omitted"

> 2. Why MUST a feed point to an alternate version. What if the feed is all

http://blogs.law.harvard.edu/tech/rss#requiredChannelElements

- Sam Ruby

---

From: Brent Simmons <[email-masked]>
Date: Wed, 12 Jan 2005 19:10:36 -0800

> the link and title may be omitted"

It's weird, but true, and I suspect that every aggregator author has 
already taken this into account. There are indeed RSS 2.0 feeds that 
don't have <link> elements. An example is 
http://www.scripting.com/rss.xml

I don't think it would be a hardship were atom:link to be optional, 
given the circumstances. I myself would probably prefer it be required, 
but only because aggregator users expect that items will have 
permalinks.

-Brent

---

From: Eric Scheid <[email-masked]>
Date: Thu, 13 Jan 2005 12:47:39 +1100

On 13/1/05 11:03 AM, "Antone Roundy" <[email-masked]> wrote:

>>>>> 2. Why MUST a feed point to an alternate version. What if the feed
>>>>> is all I publish?
>>>> 

NetNewsWire does know how to handle if present, but it doesn't panic if it's
missing.

e.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 12 Jan 2005 22:57:03 -0500

> http://blogs.law.harvard.edu/tech/rss#requiredChannelElements

OK, Sam has swayed me.

If there are masses of publishers eager to do away with that 
restriction, they will. And someone will come back and change the spec 
to reflect reality. However, that link element often just points at a 
web page that vaguely relates to the origin of the feed. That seems ok 
to me, in the absence of a better alternate.

Remember folks, this is about feed-level links, not entries. Links in 
entries are allowed to be omitted if there's atom:content 
(PaceContentOrLink, format-04).

Robert Sayre

---

From: Martin Duerst <[email-masked]>
Date: Thu, 13 Jan 2005 17:35:56 +0900

>I'm -1 on removing this restriction.

I don't see any clear justification in the above mail thread
for having the restriction. And I think that in a very fundamental
way, it's a mistake; feeds should be architected as independent
technology, not as an adjunct to Web pages.

For example, there is no restriction that every Web page has an
email address (although such an address was on many Web pages
(that was before spam)). Likewise, there is no restriction
that every email or Web page point to a feed. Or that every
chat channel has an associated feed or Web page. Integration
of these communication media is extremely important, but
forcing a link is not the right way to go.

Regards,    Martin.

---

From: Lucas Gonze <[email-masked]>
Date: Wed, 12 Jan 2005 23:48:38 -1000 (HST)

> technology, not as an adjunct to Web pages.

I also see no reason for feeds to be shadows of web pages.  The value of 
the link in the root element is to have a path towards the human or 
organizational source of a document.  Return paths are useful but not a 
requirement on the web.

---

From: Norman Walsh <[email-masked]>
Date: Thu, 13 Jan 2005 07:42:02 -0500

/ Sam Ruby <[email-masked]> was heard to say:
| Norman Walsh wrote:
|> 2. Why MUST a feed point to an alternate version. What if the feed is all
|>    I publish?

I feel I should say that I was just asking the question, I don't have
a strong feeling one way or the other. My attention has been elsewhere
for several months and I've missed a lot of the discussion. Apologies
for causing old issues to be rehashed.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Life always comes to a bad end.--Marcel
http://nwalsh.com/            | Aymé

---

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

On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby <[email-masked]>  
wrote:

>> 2. Why MUST a feed point to an alternate version. [...]
>

I thought we came to a sort of consensus that the link should be optional.  
Or was that only for atom:entry? Anyway, I think both of them should be  
optional. That is, I disagree with you, Sam.

---

From: Martin Duerst <[email-masked]>
Date: Wed, 26 Jan 2005 10:03:39 +0900

>optional. That is, I disagree with you, Sam.

I agree with Asbjoern.     Regards,   Martin.

---

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

Martin Duerst wrote:
> 
> At 01:51 05/01/26, Asbj�n Ulsberg wrote:
>  >

There is consensus that atom:link is not required for atom:entries which
contain content.  That consensus has been reflected in the most recent
drafts.  That is not the question referred to above.

There are now, by some counts, ten versions of formats that call
themselves RSS.  Every last one of then has a required channel/link.
Every last one of them.

Relaxing a restriction requires consumers to handle more cases.  My
expectation is that given limited demand for this feature, the more
likely scenario is that consumers will either produce unexpected results
or outright fail for feeds without this data.

Because of this, I would like to request that there be a compelling use
case be found which for feeds for which there can not be a atom:link
defined.  Note atom:link is defined as a URI.  While most examples that
we have seen use the HTTP scheme, this is not a requirement.  Given that
this is not a requirement, and given that existing RSS producers have
come out in mass demanding that this restriction be lifted from RSS, I
can only conclude that the burden seems rather low.

- Sam Ruby

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sat, 29 Jan 2005 07:01:28 +0100

> themselves RSS.  Every last one of then has a required channel/link.

Yes.

> Relaxing a restriction requires consumers to handle more cases.

How much does it cost for consumers to handle these cases compared to how  
much it restricts the producers? With this restriction, all Atom feeds  
needs to be a copy of another resource type. It can never be a first class  
resource. I think feed level alternative links are useful, but not more  
than that they need to be a SHOULD, not MUST.

> defined.

I would much rather require 'rel="self"' than 'rel="alternate"'. The  
former doesn't require anyone to double-produce anything, while the latter  
almost always requires people to have some kind of HTML representation of  
their feed lying around somewhere. If all the consumer and producer's  
interested in is the Atom feed, why would one need a secondary resource  
that the feed can point to?

I cannot understand why the alternative HTML page is needed. If people  
mystically and by mere coincidence subscribe to a feed without an  
alternate resource in their aggregator, how can this hurt anyone? The will  
be subscribed, have all the entries show up in their aggregators, but not  
be able to view the feed in another format.

>  Note atom:link is defined as a URI.  While most examples that
> we have seen use the HTTP scheme, this is not a requirement.

No, but we've also seen that most other schemes are totally useless in  
practice. What should an aggregator do with a 'news' scheme, for instance?  
What about 'prospero'? What about proprietary schemes that aren't  
registered in IANA and only retreivable through some sort of direct TCP  
socket? We have lots of these inside the Norwegian Broadcasting  
Corporation; we are an old publisher and broadcaster.

I do not see why we (or anyone else) should be required to publish all the  
content we wish to syndicate to users, other companies and such, in  
alternative formats to Atom, just because the Atom specificatino requires  
it. If we don't do it to please our users, I don't see why we should do it  
at all. Just to comply with a specification is imho not a good enough  
reason.