[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sub-typing Atom documents
The app:accept can be used in service documents as well as embedded in app:collection inside feeds. That seems to be the best target for extension. 

There are only two ways I know of to extend app:accept -

1. media type parameters
2. attributes to be used with app:accept
draft-gregorio-atom-multipart uses #2 and James is suggesting using #1. Is there any other kind of extension that is possible? 

Thanks,
Nikunj
http://o-micron.blogspot.com



On Jun 11, 2009, at 10:37 AM, jasnell@xxxxxxxxx wrote:
That's possible also but not all the use cases we're dealing with here involve service documents. We need a method of identifying the kind of atom documents we're dealing with at a finer level of detail than that currently allowed by the existing atom media type. 

- james
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Joe Gregorio <joe@xxxxxxxxxxxxxx>

Date: Thu, 11 Jun 2009 13:33:15
To: James M Snell<jasnell@xxxxxxxxx>
Cc: Nikunj R. Mehta<nikunj.mehta@xxxxxxxxxx>; atom-syntax Syntax<atom-syntax@xxxxxxx > 
Subject: Re: Sub-typing Atom documents
On Tue, Jun 9, 2009 at 6:24 PM, James M Snell<jasnell@xxxxxxxxx> wrote: 

I've already started working up an I-D for a new profile media type
parameter. I should be able to get it published by tomorrow end-of- day 

Example:

 application/atom+xml;profile="http://example.org/profile/foo";
The profile parameter value is a URI that identifies a logical profile to which the Atom document conforms. Only a single profile value is allowed for 
now.
Why not extend the Service Document with extra information about what the server 
will accept? That was the point of the service document which was to
contain that
kind of information.

 Thanks,
  -joe



- James

Nikunj R. Mehta wrote:
Several recent discussions suggest the need for sub-typing Atom documents. 
There are two major requirements for sub-typing Atom documents:
1. In Atom Publishing Protocol, signaling the requirement for an Atom extension (whether blessed by IETF or not) to be present in accepted content 
[1]. To illustrate the requirement by example, one would see:
<app:accept>application/atom+xml;type=entry;extension=token</ app:accept>
2. Establishing an expectation on an Atom processor for the media type of a linked resource, e.g., whether the representation in-lines a complete hierarchy of Atom entries and feeds [2]. Once again to illustrate the 
requirement by example, one would see:
<atom:link rel="down" type="application/atom+xml;type=feed;inline- depth=1" 
href="children"/>
Of these cases, a really strong case can be made for the first requirement to use a media type parameter, since it has to happen in the absence of the actual Atom document. There is only one must-understand signaling mechanism in AtomPub and that is app:accept. If a media type parameter is used in app:accept that cannot be understood by its receiver, the receiver has no choice but to cease communications with the server. Since almost every 
AtomPub-style "API" introduces its own set of requirements for what
constitutes an entry the server is willing to accept.
For example, Google Finance API in its protocol reference states that an entry posted as a new portfolio must include a "gf:portfolioData" element inside an atom:entry [3]. CMIS servers may require the presence of a type identifier as extended entry metadata in order to accept an entry posted to 
a collection [4].
It seems quite reasonable to establish a single media type parameter and allow every such API to define their own acceptable values for this purpose. This approach provides fair warning and enables AtomPub niches to legally 
exist, and even interoperate.
The second case can probably benefit from a media type parameter, but it is not clear what the semantics of that parameter would be. Specifically:
1. Do Atom processors fail if, when processing Content-Type header, they encounter a media type parameter they don't know about or a value in a known media type parameter that they don't understand. 
  2. Does introduction of media type parameters for
     application/atom+xml require standards track RFC?


Nikunj
http://o-micron.blogspot.com

[1] http://www.imc.org/atom-protocol/mail-archive/msg11398.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg21114.html
[3]
http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios
[4] http://www.oasis-open.org/committees/download.php/32668







--
Joe Gregorio        http://bitworking.org