Great reference. That's an issue oracle filed recently. The first bullet in #259 is precisely the reason why we need to have either a media type parameter (media type signals tree or flat) or down-tree link relation.
I do not believe those questions need to be answered to signal that the atom document referenced by a link element contains inline (hierarchy) or not.. If the inline I-D does not address that bullet in some way, I would prefer not to have the inline I-D so CMIS can provide a extension-specific solution until the new atom wg (if formed) comes up with a new specification that addresses hierarchy. -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 [email protected] 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. From: "Nikunj R. Mehta" <[email protected]> To: Al Brown/Costa Mesa/i...@ibmus Cc: James M Snell <[email protected]>, atom-syntax Syntax <[email protected]> Date: 06/10/2009 11:20 AM Subject: Re: Sub-typing Atom documents I find it difficult to incorporate the specification of a media type parameter to specify inline depth in the absence of a specific proposal for how to construct deeply nested hierarchy in the face of up and down links as well as multi-parents. It only makes sense to specify the media type parameter once a specific meaning or a value space can be defined. I am not sure a viable proposal exists (partly because of questions such as those raised in [1]), but I'd be happy to work with anyone's proposal that addresses this concern. Nikunj http://o-micron.blogspot.com [1] http://tools.oasis-open.org/issues/browse/CMIS-259 On Jun 10, 2009, at 10:59 AM, 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? 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. 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. -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 [email protected] 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. <graycol.gif>James M Snell ---06/09/2009 03:46:22 PM---I've already started working up an I-D for a new profile media type <ecblank.gif> <ecblank.gif> From: James M Snell <[email protected]> <ecblank.gif> <ecblank.gif> To: "Nikunj R. Mehta" <[email protected]> <ecblank.gif> <ecblank.gif> Cc: atom-syntax Syntax <[email protected]> <ecblank.gif> <ecblank.gif> Date: 06/09/2009 03:46 PM <ecblank.gif> <ecblank.gif> 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
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
