Subject: Comments on format-05

From: Mark Nottingham <[email-masked]>
Date: Sat, 29 Jan 2005 23:48:29 -0800

A few comments as I read the latest draft; apologies if I've missed 
relevant discussion, a pointer would be greatly appreciated in that 
case.

* 3.1 Text Constructs -- Since the atom:content no longer references 
this construct, my preference would be to remove this section 
altogether and make atom:title, atom:copyright, atom:summary, 
atom:tagline and atom:info have simple textual content. Do people have 
use cases where there needs to be markup in the atom:copyright, and 
will user agents really be able to use this information? If so, why 
doesn't atom:author allow markup for the Person's name as well? It 
would be odd, for example, to allow publishers to affect the 
presentation of the title, but not the author's name.

My gut feeling is that removing the markup from these elements will 
make the spec much simpler and easier to implement, without sacrificing 
many (if any) use cases. If I'm not aware of someone's use case here, 
I'm sorry and I'd love to hear about it.

* 4.2.1 Usage of "atom:head" within "atom:entry" -- This doesn't seem 
clean; I know that people have use cases for it, but I'd like to 
register my preference to get rid of it, FWIW.

* 4.11 The "atom:host" Element -- I'm surprised to see this in an IETF 
specification; people are going to make bad assumptions about the 
content of this, and violate layering to populate it. At the VERY 
least, I'd expect to see text in Security Considerations about it.

* 4.13.2 The "scheme" Attribute -- I have a slight preference for 
getting rid of atom:category/@scheme and making atom:category a generic 
categorisation mechanism; if people want to use a specific scheme, they 
can add an Atom extension. I can see arguments for how it's done, 
however.

* 4.15 The "atom:content" Element -- I strongly believe that more than 
one atom:content should be allowed; there are use cases when there are 
multiple representations of the item, and it is useful and necessary to 
communicate this in the feed. I suggest that multiple atom:content 
elements be allowed, as long as they have different type attributes.

* 4.21 The "atom:info" Element -- If it's not considered meaningful for 
processors, why does there need to be a standard element for it? At the 
very least, some sort of information about its semantics should be 
documented. My preference would be to drop it.

--
Mark Nottingham     http://www.mnot.net/

---

From: Graham <[email-masked]>
Date: Sun, 30 Jan 2005 13:59:34 +0000

On 30 Jan 2005, at 7:48 am, Mark Nottingham wrote:

> If so, why doesn't atom:author allow markup for the Person's name as 
> well? It would be odd, for example, to allow publishers to affect the 

Some people already use italics in their titles. Who has italics in 
their name? Requiring people to strip out isn't good.

> register my preference to get rid of it, FWIW.

I think it's alright but it needs an awful lot more explanation in the 
spec, of precedence rules etc.

> * 4.21 The "atom:info" Element -- If it's not considered meaningful 
> for processors, why does there need to be a standard element for it? 
> At the very least, some sort of information about its semantics should 
> be documented. My preference would be to drop it.

Yes. I thought it already was.

Graham

---

From: Eric Scheid <[email-masked]>
Date: Mon, 31 Jan 2005 03:21:06 +1100

> presentation of the title, but not the author's name.

I can see the use of some basic formatting in titles (eg. italicising
special terms), particularly in technical journals, especially
biology/medicine. With atom:summary, it would be quite important to allow
basic formatting.

> many (if any) use cases.

As for atom:copyright, atom:tagline, and atom:info ... I also can't see the
need for any formatting options.

> register my preference to get rid of it, FWIW.

+1 to getting rid of it -- the use cases are not common enough, I think.

> elements be allowed, as long as they have different type attributes.

+1, but not just type attributes, also xml:lang variations please.

e.

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 11:47:31 -0500

>+1, but not just type attributes, also xml:lang variations please.

-1. An Atom entry is *one* representation and you can link to alternates.
I'm deeply unhappy that this was raised again. We went over and over on 
the matter, and no one ever used them anyway.

Robert Sayre

---

From: Anne van Kesteren <[email-masked]>
Date: Sun, 30 Jan 2005 17:59:33 +0100

>>> * 4.15 The "atom:content" Element -- I strongly believe that more
>>>  than one atom:content should be allowed; there are use cases
>>> when there are multiple representations of the item, and it is
>>> useful and necessary to communicate this in the feed. I suggest
>>> that multiple atom:content elements be allowed, as long as they
>>> have different type attributes.
>> 
> -1. An Atom entry is *one* representation and you can link to 
> alternates. I'm deeply unhappy that this was raised again. We went 
> over and over on the matter, and no one ever used them anyway.

+1. I think it is important to include multiple translation in a single
feed.

The option of giving people alternatives makes sense too. Especially
since there is no option for a fallback mechanism.

Furthermore, as pointed out before, that restraint does not make much
sense since you can easily emulate the whole fallback thing with XHTML
which is allowed as content model.

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

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 12:07:43 -0500

Mark Nottingham wrote:

> make the spec much simpler and easier to implement, without 
> sacrificing many (if any) use cases. If I'm not aware of someone's use 
> case here, I'm sorry and I'd love to hear about it.

It doesn't really matter, and I'd wager everyone has a pet element that 
they want to use HTML in. (Blogger's titles...)

I'll explain why it's not a problem. In Thunderbird's RSS reader, titles 
are displayed in the messages pane where the "subject:" header would 
reside, thus there can be no markup. However, RSS2 items are not 
required to have titles, so sometimes the description is excerpted. This 
requires stripping HTML. The code is already there.

In a "newspaper" view in something like bloglines or feeddemon, more 
html could pass through.

> least, I'd expect to see text in Security Considerations about it.

I don't understand your objections here. I understood them when they 
were in the Person construct, but I don't anymore.

> be documented. My preference would be to drop it.

People use this heavily already. One example is FeedBurner feeds that 
incorporate Atom feeds. They know they can show the info element as an 
explanation. Without a standard element, they will have to write 90% 
similar code for every blogging vendor. It should be standardized.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 12:10:57 -0500

> +1. I think it is important to include multiple translation in a single

I'm sorry, this was decided months ago. Why don't you go back and read 
why it happened.
If we have multilple content elements, I propose that we rename it to 
<element>.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Sun, 30 Jan 2005 12:42:56 -0500

> similar code for every blogging vendor. It should be standardized.

This element only provides any value in commonly deployed browsers if 
the content type is text/xml or application/xml.

I am opposed to text/xml for a number of reasons.

We should either explicitly allow application/xml in section 2, or 
remove this element.  I'm not sure which I prefer.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 12:47:13 -0500

Sam Ruby wrote:

>>> At the very least, some sort of information about its semantics 
>>> should be documented. My preference would be to drop it.
>>
>>
>> incorporate Atom feeds. They know they can show the info element as 
>> an explanation. Without a standard element, they will have to write 
>> 90% similar code for every blogging vendor. It should be standardized.
>
>

I think that's a false dichotomy. Sometimes, the feed is incorporated 
into other media types (text/xml, application/xml, application/rss+xml, 
application/rdf+xml ...). The info:element is of use here.

Robert Sayre

---

From: Eric Scheid <[email-masked]>
Date: Mon, 31 Jan 2005 04:49:13 +1100

> the matter, and no one ever used them anyway.

At first blink what you propose sounds right, but on further reflection I
can see problems...

Say I have an <entry> which has content with @type=HTML, and an alternate
which would have @type=XHTML ... you are suggesting that the <entry> contain
a <link> like this...

    <link href="..." type="text/html" rel="alternate" />

The problem here is that looks like a link to a full fledged HTML page, not
a pointer to just the content which could be fetched and displayed in a feed
reader as a fall back position, which is what the "zero or more
atom:content" structure would allow.

Perhaps instead the link could be to an Atom Entry Document which has the
content in the alternate form (or language)... again, looking at the detail
shows there are problems...

    <link href="..." type="application/atom+xml" rel="alternate" />

Obviously it gives no indication whatsoever what the @type is for the
embedded <content> of the referenced <entry>, and if there are multiple
alternates with differing /entry/content/@type values, they would all look
the same apart from the @href. You can't even use content-negotiation on the
alternate links, since they are all application/atom+xml.

Incidentally, that looks awfully like an auto-discovery link to an Atom Feed
Document ... which is a separate problem I hope we can fix in the
auto-discovery spec and the atom spec (rel="feed" anyone?)

e.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 30 Jan 2005 12:56:30 -0500

> application/rdf+xml ...). The info:element is of use here.

Then I am clearly confused.

At the moment, the feedvalidator would mark an atom feed as invalid if 
it were served with the text/plan, application/rss+xml, or 
application/rdf+xml media types.  It accepts as valid text/xml (if the 
feed is either ASCII or a charset is explictly defined), 
application/xml, or application/atom+xml.

Given this, how should the feedvalidator change (if at all)?  How should 
the spec change (if at all)?

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 13:15:15 -0500

Sam Ruby wrote:

> Given this, how should the feedvalidator change (if at all)?  How 
> should the spec change (if at all)?

Take a look at this in a browser that does xsl transformations:
http://feeds.feedburner.com/FreeformGoodness

That feed happens to be Atom, but the service lets you target RSS1.0 and 
RSS2 as well. A large part of that feed's content comes from this feed: 
http://www.freeke.org/ffg/index.atom, which is served with the Atom 
media type.

IMHO, the spec and feed validator shouldn't conflate validity with media 
types, but I understand it's useful as shorthand for less technical 
people. So, no change to the spec is necessary. I understand you are 
looking for the spec to guide the validators behavior, but I don't think 
it should.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Sun, 30 Jan 2005 14:13:47 -0500

> looking for the spec to guide the validators behavior, but I don't think 

I am still confused.

Transforming an Atom feed into another format does not result in a valid 
Atom feed.

If I am conflating validity with media types, then so is the XML 
specification.

If the validator does not look to the spec for guidance, where should it 
look?

If somebody can answer my questions, I would appreciate it..

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 14:21:24 -0500

Sam Ruby wrote:

> I am still confused.
>
> Transforming an Atom feed into another format does not result in a 
> valid Atom feed.

Right, but it's useful for the tranformation.

> If I am conflating validity with media types, then so is the XML 

I don't understand that, could you explain?

>
> If the validator does not look to the spec for guidance, where should 
> it look?
>

I think the spec should cover Atom documents identified with the Atom 
media type. Other types are undefined.

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Sun, 30 Jan 2005 14:34:21 -0500

> I don't understand that, could you explain?

See the XML specification section F.2 [1].  It is quite possible for an 
XML document to be valid if served with media type application/xml, but 
for the same document to be valid if served with a media type of text/xml.

Not a situation that I particularly care for.  And it is widely ignored. 
  But that's what the specs say.

> media type. Other types are undefined.

If the behavior is undefined, then people should not expect 
interoperability.  If the only use case for atom:info is based on 
depending on something that is undefined, then atom:info should be tossed.

- Sam Ruby

[1] http://www.w3.org/TR/REC-xml/#sec-guessing-with-ext-info

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 15:09:25 -0500

Sam Ruby wrote:

>  See the XML specification section F.2 [1]. It is quite possible for
>  an XML document to be valid if served with media type
>  application/xml, but for the same document to be valid if served with
>  a media type of text/xml.
>
>  Not a situation that I particularly care for. And it is widely
>  ignored. But that's what the specs say.

(the following is more irritating than my actual personality...)

The XML specification defines validity in terms of DTDs.
The XML specification defines violation of a well-formedness constraint 
as a fatal error.
The XML specification defines an illegal byte sequence during decoding 
as a fatal error.

It is quite possible for an XML document to be served with an incorrect 
media type and remain well-formed and valid.

Atom documents are well-formed, but not valid, according to the XML spec.
http://www.w3.org/TR/REC-xml/#sec-prolog-dtd

>
> >> If the validator does not look to the spec for guidance, where
> >> should it look?
> >>
> > I think the spec should cover Atom documents identified with the
> > Atom media type. Other types are undefined.
>
>

atom:info is useful during transformations. Tossing atom:info will 
result in interoperability problems. I don't see how application/xml 
relates, but if I were forced to make the choice, I would drop atom:info.

Robert Sayre

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Jan 2005 12:13:13 -0800

On Jan 30, 2005, at 9:07 AM, Robert Sayre wrote:

>> sacrificing many (if any) use cases. If I'm not aware of someone's 
>> use case here, I'm sorry and I'd love to hear about it.
>
> It doesn't really matter, and I'd wager everyone has a pet element 
> that they want to use HTML in. (Blogger's titles...)
>
> I'll explain why it's not a problem. In Thunderbird's RSS reader, 
> titles are displayed in the messages pane where the "subject:" header 
> would reside, thus there can be no markup. However, RSS2 items are not 
> required to have titles, so sometimes the description is excerpted. 
> This requires stripping HTML. The code is already there.
>

Fair enough. I think that everyone will end up stripping, and therefore 
everyone will end up having to implement that; for some people, that 
will raise the cost considerably (e.g. escaping broken, escaped HTML in 
XSLT). Sigh.

>> * 4.11 The "atom:host" Element -- I'm surprised to see this in an 
>> IETF specification; people are going to make bad assumptions about 
>> the content of this, and violate layering to populate it. At the VERY 

Because people are going to do the same thing; "well, this comment post 
came from that IP address via HTTP, so I'll put that into atom:host; 
after all, it's in the spec, so it must be important."

> similar code for every blogging vendor. It should be standardized.

It's great that they're using it, but from reading the spec, I have no 
idea what atom:info is suppose to contain, or why. What is a 
"human-readable explanation of the feed format"?

My understanding was that publishers could include a PI that pointed to 
a transform that, in XSL-capable browsers that aren't aware of Atom, 
present a nice HTML page. That's great, but why does it need to be 
standardized? If they control the transform and the feed, they can do 
the exact same thing with a foo:blag extension element, with no loss of 
function, interoperability, or ease of implementation. What am I 
missing here?

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Jan 2005 21:24:35 +0100

Mark Nottingham wrote:

 > ...

+1

There may be good reasons for atom:host and atom:info to be there, but 
they aren't really obvious by reading the spec alone.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Tim Bray <[email-masked]>
Date: Sun, 30 Jan 2005 12:34:24 -0800

> relates, but if I were forced to make the choice, I would drop 

I have ABSOLUTELY NO IDEA what it is that Sam and Rob are arguing 
about.  I suspect I'm not the only one.  Could someone please explain 
the problem in basic terms? -Tim

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Jan 2005 12:41:55 -0800

Big +1!

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 15:52:19 -0500

Tim Bray wrote:

> the problem in basic terms? 

Sam wants the spec to guide the feed validator when it encounters feeds 
served with media types other than Atom's.

I don't want the spec to talk about HTTP or other media types.

Sam is saying atom:info is used only when feeds are served with the 
wrong media type, so we shouldn't include it unless we are going to 
cover other media types.

I maintain that atom:info has uses when Atom feeds are served as 
application/atom+xml.

Robert Sayre

---

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Jan 2005 22:08:35 +0100

>> the problem in basic terms? 

Thanks, Robert.

> I don't want the spec to talk about HTTP or other media types.

I think it's enough to say that if it doesn't come with the right media 
type, it's outside the scope of the spec (same for wellformed-ness 
errors and so on...).

> I maintain that atom:info has uses when Atom feeds are served as 

Interesting. Can anybody summarize what atom:info is *currently* used for?

Best regards, Julian

---

From: Sam Ruby <[email-masked]>
Date: Sun, 30 Jan 2005 17:57:31 -0500

Julian Reschke wrote:

>> Sam wants the spec to guide the feed validator when it encounters 
>> feeds served with media types other than Atom's.
>>

I want the spec to say what are valid media types for Atom feeds.  Any 
other media type may work in some software combinations, but aren't 
guaranteed to work in any.

> Interesting. Can anybody summarize what atom:info is *currently* used for?

Here is a live example of atom:info in use:

   http://www.shellen.com/atom.xml

View source.  View in your favorite browser.

- Sam Rubys

---

From: Bill de hÓra <[email-masked]>
Date: Sun, 30 Jan 2005 23:58:24 +0000

> were in the Person construct, but I don't anymore.

I kind of agree with Mark on this, but I'd be reluctant to re-open that 
debate. I think getting atom:host out of Person was a decent trade-off.

cheers
Bill

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Jan 2005 18:11:56 -0800

I'm not going to lie down in the road to get rid of atom:host, if there 
are a lot of people that want it badly. However, it should be more 
completely specified; i.e., some mention in security considerations, 
and also, more information about the association.

Right now, it's just "domain name or network address associated with an 
entry's origin." What is that association? It feels very much like 
atom:date, when it had a date, but no indication of what the date 
represented; i.e., it's just a datatype (in this case, a hostname or ip 
address), but no information about *how* it relates to the entry or 
feed.

Cheers,

On Jan 30, 2005, at 3:58 PM, Bill de hÓra wrote:

>>> the content of this, and violate layering to populate it. At the 
>>> VERY least, I'd expect to see text in Security Considerations about 
>>> it.
> I kind of agree with Mark on this, but I'd be reluctant to re-open 
> that debate. I think getting atom:host out of Person was a decent 
> trade-off.
>
> cheers
> Bill
>
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Jan 2005 18:40:30 -0800

OK. So, why is it necessary to standardise this element? Look at
    http://www.mnot.net/test/atom.xml

which is the same feed, but with atom:info replaced by a 'foo' element. 
Because the atom document has to reference the CSS anyway, it's 
entirely reasonable to have the css specify what element to use for the 
info. No functionality is lost, and no interoperability is lost.

BTW, if you don't want to put a link in the text, you don't need to put 
anything in the XML at all; it can be done with :after. And, if you use 
XSLT, it's also possible to do it all in-stylesheet, with or without 
links.

Cheers,

---

From: Graham <[email-masked]>
Date: Mon, 31 Jan 2005 03:03:47 +0000

> which is the same feed, but with atom:info replaced by a 'foo' element.

Even better, you can drop foo and put the xhtml div as a direct child 
of feed. Then use feed > div as the selector.

> And, if you use XSLT, it's also possible to do it all in-stylesheet, 
> with or without links.

Safari (and probably other things) don't do XSLT.

Graham

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Jan 2005 19:20:19 -0800

> of feed. Then use feed > div as the selector.

Nice!

> Safari (and probably other things) don't do XSLT.

Fair enough.

---

From: Sam Ruby <[email-masked]>
Date: Sun, 30 Jan 2005 22:32:10 -0500

>> of feed. Then use feed > div as the selector.

What type of XML document is this?  It isn't served with Atom's media 
type.  Is it still an Atom document?

I want the spec to be able to answer with a "yes" or a "no" to that 
question.

Is that too much to ask?

- Sam Ruby

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Jan 2005 19:44:20 -0800

Good question. If it's served with Atom's media type, most (but not 
all, I suspect) browsers will ask how to dispatch it, or just save the 
file; some might optimistically try to handle it themselves, based on 
the "+xml".

In the case that they dispatch it elsewhere (including the local 
filesystem), atom:info -- or any other technique discussed -- atom:info 
won't provide any value. In the case where they try, any of the 
proposed mechanisms (atom:info, using a locally specific (e.g., foo) 
element,  just putting the html div in the feed) will work.

If it's served with another media type, it isn't atom, and is a 
deployment error that experience tells us will be somewhat common. In 
that case, the behaviour will largely depend on the configuration of 
the Web server, in which case the choices are the same as above.

So, the relevant question seems to be whether any browsers do something 
interesting with +xml media types; if they don't and we don't believe 
that they will, it's an argument to get rid of atom:info. If they do, 
the arguments to get rid of atom:info still remain, because there's a 
viable alternative.

Cheers,

On Jan 30, 2005, at 7:32 PM, Sam Ruby wrote:

>>> Even better, you can drop foo and put the xhtml div as a direct 
>>> child of feed. Then use feed > div as the selector.
>> Nice!
>

---

From: Joe Gregorio <[email-masked]>
Date: Sun, 30 Jan 2005 22:51:21 -0500

> address), but no information about *how* it relates to the entry or

I believe atom:host is the long lost descendent of atom:ipaddr, which came from 
the problem I had implementing Atom on wiki, where the 'author' of an
entry can be difficult to pin down and the ip address may be the only
information available. If atom:host is what the 'solution' has morphed
into, than I'd rather see it dropped. When putting together a feed for
a wiki in Atom I could just as easily set the atom:name element to:

<atom:name>Anonymous</atom:name>

or 

<atom:name>Anonymous (from IP: aaa.bbb.ccc.dddd)</atom:name>

    -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 22:53:49 -0500

Mark Nottingham wrote:

> interesting with +xml media types; 

No, the relevant question is whether +xml media types can be reliably 
dispatched without any knowledge of a specific scheme. I don't know the 
answer, but I do know that it's a question for the RFC that supercedes 
3023, not Atom.

If I tell NetNewsWire to GET something in the subscribe dialog, my 
dispatching instructions are clear. Everything is a feed. Making up 
rules for application/xml, text/xml, and application/octet-stream will 
require superceding some RFCs that I'd rather not mess with.

Robert Sayre

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 30 Jan 2005 20:02:32 -0800

RFC 3023, Section 7:

>    This document recommends the use of a naming convention (a suffix of
>    '+xml') for identifying XML-based MIME media types, whatever their
>    particular content may represent.  This allows the use of generic 
> XML
>    processors and technologies on a wide variety of different XML
>    document types at a minimum cost, using existing frameworks for 
> media
>    type registration.
[...]
> Some areas where 'generic' processing is useful include:
>
>    o  Browsing - An XML browser can display any XML document with a
>       provided [CSS] or [XSLT] style sheet, whatever the vocabulary of
>       that document.
[...]
> This convention will allow
>    applications that can process XML generically to detect that the 
> MIME
>    entity is supposed to be an XML document, verify this assumption by
>    invoking some XML processor, and then process the XML document
>    accordingly.

On Jan 30, 2005, at 7:53 PM, Robert Sayre wrote:

> Mark Nottingham wrote:
>
>> So, the relevant question seems to be whether any browsers do 
>> something interesting with +xml media types;
>
> dispatched without any knowledge of a specific scheme. I don't know 
> the answer, but I do know that it's a question for the RFC that 
> supercedes 3023, not Atom.
>

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 23:09:14 -0500

Joe Gregorio wrote:

> into, than I'd rather see it dropped.

Thanks for bringing up this "problem".

> <atom:name>Anonymous (from IP: aaa.bbb.ccc.dddd)</atom:name>

Yay! Let's drop atom:host.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Sun, 30 Jan 2005 23:14:10 -0500

If we don't want Atom to be processed by "generic XML processors and 
technologies" and dispatched accordingly, then the correct course of 
action would be to choose a media type without the "+xml" suffix. I 
still don't see how this relates to atom:info.

Robert Sayre

Mark Nottingham wrote:
>>    particular content may represent.  This allows the use of generic XML
>>    document types at a minimum cost, using existing frameworks for media
>>    type registration.
> 
> [...]
> 
>>    applications that can process XML generically to detect that the MIME

---

From: Tim Bray <[email-masked]>
Date: Sun, 30 Jan 2005 20:42:41 -0800

> Yay! Let's drop atom:host.

+1 oh yes please, I always thought it was lame-ass. -Tim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Jan 2005 09:46:44 +0100

>> Safari (and probably other things) don't do XSLT.

Safari is said to get a (libxml-based) XSLT engine in the next major 
upgrade.

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 31 Jan 2005 14:50:13 +0100

>require superceding some RFCs that I'd rather not mess with.

What makes you think that "everything is a feed" might be consistent
with these RFCs?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Robert Sayre <[email-masked]>
Date: Mon, 31 Jan 2005 09:06:12 -0500

>What makes you think that "everything is a feed" might be consistent

This is what media types are for:

"The purpose of the Content-Type field is to describe the data
contained in the body fully enough that the receiving user agent can
pick an appropriate agent or mechanism to present the data to the
user, or otherwise deal with the data in an appropriate manner. The
value in this field is called a media type."

In the subscribe dialog, I always know what the appropriate agent is. 
What makes you think "standards" dictate some other behavior?

Robert Sayre

---

From: Sam Ruby <[email-masked]>
Date: Mon, 31 Jan 2005 09:44:47 -0500

> What makes you think "standards" dictate some other behavior?

Counter example: one that is all too common.  If you get back something 
with a content type of text/html, what you are probably getting back is 
an error message with some useful information.

Other counter examples include some of the security holes that have been 
created by people serving executable content as text/plain (getting past 
some important security checks), and then getting executed by code that 
*thinks* it always knows what the appropriate behavior is.

Interoperability will be improved if we can nail down what are valid 
media types that atom feeds can be served with, and what are invalid 
media types that should always be rejected.

We can build voluntary conformance test suites for aggregator developers 
to test against.

The feedvalidator can provide feedback to content producers.

- Sam Ruby

---

From: Robert Sayre <[email-masked]>
Date: Mon, 31 Jan 2005 10:06:24 -0500

Sam Ruby wrote:

> We can build voluntary conformance test suites for aggregator 
> developers to test against.
>

The charter does include "clearly nominating conformance levels for 
different types of software". A short I-D or appendix on serving Atom 
feeds over HTTP would probably make a good product for this WG. I bet 
you could write it pretty quickly.

Robert Sayre

---

From: Antone Roundy <[email-masked]>
Date: Mon, 31 Jan 2005 11:31:24 -0700

On Sunday, January 30, 2005, at 10:49  AM, Eric Scheid wrote:
>> alternates.
Another option would be to allow one <content> with inline content, and 
alternative content by reference, eg. (not being careful about getting 
language tags correct):

<content type="TEXT" xml:lang="en_US">This is a pen</content>
<content type="text/html" hreflang="en_US" src="http://foo.com/abc" />
<content type="text/html" hreflang="jp" src="http://foo.com/aiu" />

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 31 Jan 2005 11:02:34 -0800

On Jan 31, 2005, at 10:31 AM, Antone Roundy wrote:
> Another option would be to allow one <content> with inline content, 
> and alternative content by reference, eg. (not being careful about 
> getting language tags correct):
>

I think that's the same option as allowing multiple content elements 
(unless this implies some fairly strict rules about the combinations of 
content elements allowable, which IMO would be difficult to specify and 
enforce).

If the concern about multiple content is solely that it will result in 
more bandwidth use, I think it's misplaced; people who are concerned 
about bandwidth won't publish multiple representations inline; forcing 
them not to by legislation is misguided.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 31 Jan 2005 01:11:52 -0500

I thought atom:host was made redundant by the combination of HeadInEntry and
FeedLink...

		bob wyman