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

Re: Sub-typing Atom documents




Al Brown wrote:
It would be useful to have more than one profile such that cmis + inline may be specified. Also, will you include initial values for the profile type or should that be part of CMIS and the inline I-D? 


More than one profile value is definitely possible.
Can we have specify language similar to how link relations are specified? Ie, there is a registry of names in a default namespace. Extensions are then free to register their name or use a fully-qualified URI. One added benefit of this is there will be a central registry of atom extensions, at least the ones that took the time to register them.
Again, also a strong possibility if and only if there is consensus that a central registry would be beneficial.
I also thought the media type parameter inline-depth as useful and that would be nice to have specified as part of the inline I-D.
-1... incorporating something like inline-depth=1 into the media type would not be a good thing. The media type is intended to describe the kind of document that's being passed around and not specific details about the documents construction. When I say something like "application/atom+xml;type=entry;profile=tree", what I'm saying is that the document is potentially a hierarchical Atom entry but in order to determine anything more about the document I have to retrieve and examine it directly. 

-Al

Al Brown
Emerging Standards and Industry Frameworks
CMIS: https://w3.tap.ibm.com/w3ki07/display/ECMCMIS/Home
Industry Frameworks: https://w3.tap.ibm.com/w3ki07/display/ECMIF/Home

Office 714 327 3453
Mobile 714 263 6441
Email albertcbrown@xxxxxxxxxx
CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation.
Inactive hide details for James M Snell ---06/09/2009 03:46:22 PM---I've already started working up an I-D for a new profile meJames M Snell ---06/09/2009 03:46:22 PM---I've already started working up an I-D for a new profile media type 


From: 	
James M Snell <jasnell@xxxxxxxxx>

To: 	
"Nikunj R. Mehta" <nikunj.mehta@xxxxxxxxxx>

Cc: 	
atom-syntax Syntax <atom-syntax@xxxxxxx>

Date: 	
06/09/2009 03:46 PM

Subject: 	
Re: Sub-typing Atom documents

------------------------------------------------------------------------




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.

- 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