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
