On Thursday, June 11, 2009, at 07:33PM, "Joe Gregorio" <[email protected]>
wrote:
>
>On Tue, Jun 9, 2009 at 6:24 PM, James M Snell<[email protected]> 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.
Wasn't this the intent of the features draft?
What I like about the profile parameter is that it provides the opportunity to
do a sort client side negotiation with a server that can serve up Atom in
different varieties, such as:
<feed>
<!-- ... -->
<entry>
<title>My Entry</title>
<link rel="alternate" type='application/atom+xml;
profile="http://example.org/profile/foo";'
href="http://example.org/entries/1_foo.xml"/>
<link rel="alternate" type='application/atom+xml;
profile="http://example.org/profile/bar";'
href="http://example.org/entries/1_bar.xml"/>
<!-- ... -->
</entry>
</feed>
The client could pick the variant it wants based on the profile.
Jan
On Thursday, June 11, 2009, at 07:33PM, "Joe Gregorio" <[email protected]>
wrote:
>
>On Tue, Jun 9, 2009 at 6:24 PM, James M Snell<[email protected]> 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
>
>
>
