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, [email protected] 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 <[email protected]>
Date: Thu, 11 Jun 2009 13:33:15
To: James M Snell<[email protected]>
Cc: Nikunj R. Mehta<[email protected]>; atom-syntax Syntax<[email protected]
>
Subject: Re: Sub-typing Atom documents
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
