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
