Re: Atom Entry docs

[Mark Baker]

Tim,

On 12/12/06, Tim Bray <[EMAIL PROTECTED]> wrote:


I seems obvious to me that Atom Feed and Entry docs are potentially
quite different things which can be used for entirely different
purposes.  The contention that an Entry doc is somehow really the same
as a one-entry Feed doc is entirely unconvincing.

The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG
finding on Authoritative Metadata
(http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear
that it's advantageous to use HTTP headers to distinguish between
different kinds of representations.


Ok, well, I've already voiced my disagreement that "entirely different
purposes" necessitates a new media type using HTML as an example.

I also disagree that the TAG finding has any relevance here, except
insofar as it says that a media type authoritatively determines
meaning by virtue of pointing at a spec ... but every option on the
table, including doing nothing, does that.

But so be it, I'm happy to move on ...


So I guess I'm in favor of us writing something down to address this
problem.

RFC4287 is now pretty widely implemented, so there is a distinct cost to
screwing around with the well-known application/atom+xml.  On the other
hand, my perception is that virtually all software that knows about 4287
knows about feeds, rather than entries.  Thus, it seems to me that
introducing a parameter so that existing software might see
application/atom+xml;type=feed *might* break some software.


Maybe, but I'd be surprised.  Though not, AFAIK, prescribed behaviour,
convention is that unknown extension parameters are ignored.

Implementors?


 But
introducing a new media-type application/atom-entry+xml which only goes
with standalone feed documents is very unlikely to break anything.


I think it would break servers.

Consider GData apps.  Their docs aren't clear (tsk, tsk!) about the
use of a media type when inserting entries[1], but if they're doing it
properly then their services should be keying off of
"application/atom+xml", and so will break if that's changed.

Other server implementations should have the same issue, of course.


So I'm for James' option B)
  application/atom-entry+xml


I'm -1 on that, but +1 on the type parameter.

Cheers,

[1] http://code.google.com/apis/gdata/protocol.html#Inserting-a-new-entry

Mark.

Re: Atom Entry docs

[James M Snell]

I think atom.entry and atom-entry are equally ugly; atom.entry would,
however, appear to be more consistent with typical mime conventions.

- James

Tim Bray wrote:
> 
> [snip]
> (James, did you really mean "atom.entry" with the ugly dot?)
> 
>  -Tim
> 
> 

Atom Entry docs

[Tim Bray]

I seems obvious to me that Atom Feed and Entry docs are potentially 
quite different things which can be used for entirely different 
purposes.  The contention that an Entry doc is somehow really the same 
as a one-entry Feed doc is entirely unconvincing.


The Architecture of the Web (http://www.w3.org/TR/webarch) and the TAG 
finding on Authoritative Metadata 
(http://www.w3.org/2001/tag/doc/mime-respect.html) make it pretty clear 
that it's advantageous to use HTTP headers to distinguish between 
different kinds of representations.


So I guess I'm in favor of us writing something down to address this 
problem.


RFC4287 is now pretty widely implemented, so there is a distinct cost to 
screwing around with the well-known application/atom+xml.  On the other 
hand, my perception is that virtually all software that knows about 4287 
knows about feeds, rather than entries.  Thus, it seems to me that 
introducing a parameter so that existing software might see 
application/atom+xml;type=feed *might* break some software.  But 
introducing a new media-type application/atom-entry+xml which only goes 
with standalone feed documents is very unlikely to break anything.


So I'm for James' option B)
 application/atom-entry+xml

(James, did you really mean "atom.entry" with the ugly dot?)

 -Tim

Re: Atom Entry Documents

[Tim Bray]

Mark Baker wrote:


Ok, the recent discussion seems to point towards a consensus towards
distinctly flagging Entry Documents in the media type.


Erm, isn't it up to the chairs to declare concensus?


I agree that there exists sentiment in favor of there 
being a way to distinguish between Feed and Entry documents.  I think 
the notion of consensus is only meaningful in the context of actual spec 
language, so it seems to me that it would be helpful to have some 
proposed language to look at.  So I see no downside in James doing an 
I-D.


 -Tim

Re: Atom namespace really not ending with / or # ?

[Tim Bray]

Anne van Kesteren wrote:
Jan Algermissen 
<[EMAIL PROTECTED]> wrote:
is it really true that the Atom namespace is 
http://www.w3.org/2005/Atom ?


It wasn't really relevant, I'd say. (That it says "Atom" and not "atom" 
was a mistake.)


I'd agree.  Sigh.  But not a big one, I think -Tim

Re: Atom Entry Documents

[Mark Baker]

On 12/12/06, James M Snell <[EMAIL PROTECTED]> wrote:

*If* the document proceeds to Proposed Standard, the new RFC would
update RFC4287 either by adding a new type param or by deprecating the
use of application/atom+xml for atom entry documents in favor of a new
media type.  No other part of RFC4287 would be affected.

Ideally, I would much rather this be a WG draft. I pinged Tim about it
the other day and he suggested that I go ahead with a I-D for now and
that we can explore whether or not to move forward with it as a WG draft
later.


I'm uncomfortable with this.

If there's consensus to do something about identifying entry
documents, let's do that.  If there isn't, let's not.

Mark.

Re: Atom Entry Documents

[Kyle Marvin]

Hi Mark,

I realize the question is part process and part technical, but here's my
wish for the technical portion:  I'm hoping that whatever is done can be
additive and optional, such that it can enable new capabilities without
disrupting existing usage of 4287 (only).

This is one of the reasons why I prefer that we use optional type qualifiers
(Option A) rather than deprecating one mime type and creating two new ones
(Option B).

Cheers!

-- Kyle

On 12/12/06, Mark Nottingham <[EMAIL PROTECTED]> wrote:



What would the relationship of that document be to RFC4287?

Cheers,


On 2006/12/11, at 7:32 PM, James M Snell wrote:

> The I-D would be an individual draft, not a WG draft.


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

Re: Atom namespace really not ending with / or # ?

[Bill de hOra]

Jan Algermissen wrote:


Hi,

is it really true that the Atom namespace is http://www.w3.org/2005/Atom ?

Meaning that it is somewhat difficult to identify Atom elements with URIs:

http://www.w3.org/2005/Atomauthor
http://www.w3.org/2005/Atomconributor



Was that simply a mistake or a design feature when Atom was standardized?


Thinks I asked for a trailing '/' at some point;  certainly for 
fnalising APP, I want a trailing '/'.


cheers
Bill

Re: Atom namespace really not ending with / or # ?

[Alexander Johannesen]

> http://www.w3.org/2005/Atomauthor
> http://www.w3.org/2005/Atomconributor
> 


On 12/12/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

Isn't that only relevant for RDF vocabularies?


No, it's relevant for all types of XML work, from XLink to Topic Maps
to XHTML. But there's a difference between http://www.w3.org/2005/Atom
used as a namespace declaration and a document pointer, though. For a
lot of us data modeling types it would be good to use bits of the Atom
spec in controlled vocabularies, for example, and we mix these types
of models up all the time. Umm, at least I do. :)


Alex
--
"Ultimately, all things are known because you want to believe you know."
- Frank Herbert
__ http://shelter.nu/ __

Re: Atom namespace really not ending with / or # ?

[Anne van Kesteren]

On Tue, 12 Dec 2006 08:18:49 +0100, Jan Algermissen  
<[EMAIL PROTECTED]> wrote:
is it really true that the Atom namespace is http://www.w3.org/2005/Atom  
?


Yes.


Meaning that it is somewhat difficult to identify Atom elements with  
URIs:


http://www.w3.org/2005/Atomauthor
http://www.w3.org/2005/Atomconributor



Isn't that only relevant for RDF vocabularies?



Was that simply a mistake or a design feature when Atom was standardized?


It wasn't really relevant, I'd say. (That it says "Atom" and not "atom"  
was a mistake.)



--
Anne van Kesteren

Re: Atom Entry Documents

[James M Snell]

*If* the document proceeds to Proposed Standard, the new RFC would
update RFC4287 either by adding a new type param or by deprecating the
use of application/atom+xml for atom entry documents in favor of a new
media type.  No other part of RFC4287 would be affected.

Ideally, I would much rather this be a WG draft.  I pinged Tim about it
the other day and he suggested that I go ahead with a I-D for now and
that we can explore whether or not to move forward with it as a WG draft
later.

- James

Mark Nottingham wrote:
> What would the relationship of that document be to RFC4287?
> 
> Cheers,
> 
> 
> On 2006/12/11, at 7:32 PM, James M Snell wrote:
> 
>> The I-D would be an individual draft, not a WG draft.
> 
> 
> -- 
> Mark Nottingham http://www.mnot.net/
> 
>