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.
<graycol.gif>"Nikunj R. Mehta" ---06/10/2009 11:20:26 AM---I find it
difficult to incorporate the specification of a media type parameter
to specify inline depth in the absence of a spec
<ecblank.gif>
From: <ecblank.gif>
"Nikunj R. Mehta" <[email protected]>
<ecblank.gif>
To: <ecblank.gif>
Al Brown/Costa Mesa/i...@ibmus
<ecblank.gif>
Cc: <ecblank.gif>
James M Snell <[email protected]>, atom-syntax Syntax <[email protected]
>
<ecblank.gif>
Date: <ecblank.gif>
06/10/2009 11:20 AM
<ecblank.gif>
Subject: <ecblank.gif>
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>
From: <ecblank.gif>
James M Snell <[email protected]>
<ecblank.gif>
To: <ecblank.gif>
"Nikunj R. Mehta" <[email protected]>
<ecblank.gif>
Cc: <ecblank.gif>
atom-syntax Syntax <[email protected]>
<ecblank.gif>
Date: <ecblank.gif>
06/09/2009 03:46 PM
<ecblank.gif>
Subject: <ecblank.gif>
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
