Subject: Sub-typing Atom documents

From: "Nikunj R. Mehta" <[email-masked]>
Date: Tue, 9 Jun 2009 13:57:31 -0700

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:

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.
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

---

From: Sylvain Hellegouarch <[email-masked]>
Date: Tue, 09 Jun 2009 23:38:31 +0200

> There is only one must-understand signaling mechanism in AtomPub and 
> that is app:accept.
I don't remember seeing that "must-understand", could you reference it 
please?

> 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.

What does that mean? What does "cease communication" actually mean in HTTP?

> Since almost every AtomPub-style "API" introduces its own set of 
> requirements for what constitutes an entry the server is willing to 
> accept.
>

Yes, those are foreign elements which is accepted by the spec. I don't 
follow your point.
> niches to legally exist, and even interoperate.
How do they interoperate if they aren't known by others?
>    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.
>
Client side or server side?

- Sylvain

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Tue, 9 Jun 2009 14:48:33 -0700

On Jun 9, 2009, at 2:38 PM, Sylvain Hellegouarch wrote:

>
>> There is only one must-understand signaling mechanism in AtomPub  
>> and that is app:accept.
> I don't remember seeing that "must-understand", could you reference  
> it please?

§ 8.3.4 of RFC 5023 states

[[
The media range specifies a type of
    representation that can be POSTed to a Collection.

The app:accept element is similar to the HTTP Accept request-header
    [RFC2616].  Media type parameters are allowed within app:accept
]]

I interpret this to mean that app:accept is a kind of must-understand.  
However, a client may still attempt to POST however unsuccessfully. Of  
course, there is no hard "must-understand" in AtomPub.

> What does that mean? What does "cease communication" actually mean  

IIUC, AtomPub clients will not POST to a server entries that don't  
conform to one of the acceptable content types for the collection, as  
advertised in an app:collection element through app:accept. This is  
what I meant. Of course, anything is possible in HTTP, but my  
commentary was limited to conforming AtomPub clients.

>> 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].
>
> Yes, those are foreign elements which is accepted by the spec. I  
> don't follow your point.

Point being that if you were to submit a valid Atom entry which did  
not have the foreign markup, the server would simply decline the  
request, even though it may advertise

<app:accept>application/atom+xml;type=entry</app:accept>

We had a pretty detailed discussion of this topic on atom-protocol,  
which you may wish to review [1]

>>
>> 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.

Can you specify "they"? Interoperation is only possible because the  
parties to it understand the meaning of the value of a special Atom  
media type parameter.

>>
>> 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:
>>

Why should it matter? This question is addressed to atom-syntax and  
intends to question what RFC4287 calls Atom Processors.

Nikunj

---

From: James M Snell <[email-masked]>
Date: Tue, 09 Jun 2009 15:24:31 -0700

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:
> documents. There are two major requirements for sub-typing Atom documents:
>
> <atom:link rel="down" 
> type="application/atom+xml;type=feed;inline-depth=1" href="children"/>
>
> the absence of the actual Atom document. There is only one 
> must-understand signaling mechanism in AtomPub and that is app:accept. 
>    2. Does introduction of media type parameters for
>       application/atom+xml require standards track RFC?
>
>
> Nikunj

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Tue, 9 Jun 2009 15:25:53 -0700

It would help if you can clarify which of these two requirements you  
wish to address by introducing a new media type parameter and its  
consequences. In short, we would benefit if the I-D addresses my  
questions below.

Nikunj

On Jun 9, 2009, at 3:24 PM, James M Snell wrote:

> 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:
>> 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:
>>
>> 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:
>>
>> 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.  
>> 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.
>>

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Tue, 9 Jun 2009 16:49:01 -0700

> value is allowed for now.

A single profile value could be a problem since it doesn't allow mixin  
whereas Atom's extensibility model does.

---

From: Al Brown <[email-masked]>
Date: Wed, 10 Jun 2009 10:59:51 -0700

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-masked]
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:       James M Snell <[email-masked]>                                                                                 
                                                                                                                                
  To:         "Nikunj R. Mehta" <[email-masked]>                                                                       
                                                                                                                                
  Cc:         atom-syntax Syntax <[email-masked]>                                                                          
                                                                                                                                
  Date:       06/09/2009 03:46 PM                                                                                               
                                                                                                                                
  Subject:    Re: Sub-typing Atom documents                                                                                     

Example:

- James

documents:
> [3]
http://code.google.com/apis/finance/developers_guide_protocol.html#CreatingPortfolios

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 10 Jun 2009 11:18:44 -0700

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

[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
> 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.
>
> 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
>
> From:	
> To:	
> "Nikunj R. Mehta" <[email-masked]>
> Cc:	
> Date:	
> 06/09/2009 03:46 PM
> Atom
> type
> "API"
> that
> but

---

From: James M Snell <[email-masked]>
Date: Wed, 10 Jun 2009 11:38:39 -0700

Al Brown wrote:
> 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?
>
More than one profile value is definitely possible.
> 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.
>
Again, also a strong possibility if and only if there is consensus that 
a central registry would be beneficial.
> that would be nice to have specified as part of the inline I-D.
-1... incorporating something like inline-depth=1 into the media type 
would not be a good thing. The media type is intended to describe the 
kind of document that's being passed around and not specific details 
about the documents construction. When I say something like 
"application/atom+xml;type=entry;profile=tree", what I'm saying is that 
the document is potentially a hierarchical Atom entry but in order to 
determine anything more about the document I have to retrieve and 
examine it directly.
> 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 
> 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.
>
> Inactive hide details for James M Snell ---06/09/2009 03:46:22 
> PM---I've already started working up an I-D for a new profile meJames 
> M Snell ---06/09/2009 03:46:22 PM---I've already started working up an 
> I-D for a new profile media type
>
>
> From: 	
> ------------------------------------------------------------------------
>
>
>
>

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 10 Jun 2009 11:46:38 -0700

On Jun 10, 2009, at 11:38 AM, James M Snell wrote:

> -1... incorporating something like inline-depth=1 into the media  
> type would not be a good thing. The media type is intended to  
> describe the kind of document that's being passed around and not  
> specific details about the documents construction.

This reasoning is not very useful really.

> When I say something like "application/atom 
> +xml;type=entry;profile=tree", what I'm saying is that the document  
> is potentially a hierarchical Atom entry but in order to determine  
> anything more about the document I have to retrieve and examine it  
> directly.
>

Just like type=entry says that the document contains a single Atom  
entry element, and profile=cmis1.0 says that the element has certain  
extensions, inline-depth=1 could say that the extension uses link in- 
lining to a certain depth.

The problem really is that the meaning of inline-depth is not well- 
defined.

---

From: Al Brown <[email-masked]>
Date: Wed, 10 Jun 2009 11:54:26 -0700

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

Office 714 327 3453
Mobile 714 263 6441

  From:       "Nikunj R. Mehta" <[email-masked]>                                                                       
                                                                                                                                
  To:         Al Brown/Costa Mesa/IBM@IBMUS                                                                                     
                                                                                                                                
  Cc:         James M Snell <[email-masked]>, atom-syntax Syntax <[email-masked]>                                       
                                                                                                                                
  Date:       06/10/2009 11:20 AM                                                                                               

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

      -Al

      Al Brown

      Office 714 327 3453
      Mobile 714 263 6441

                                                                           

                                                                           

      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:

      profile

      - James

      Atom
      > <app:accept>application/atom
      +xml;type=entry;extension=token</app:accept>
      type
      > requirement to use a media type parameter, since it has to happen
      in

      "API"
      that
      > It seems quite reasonable to establish a single media type
      parameter
      but

---

From: Al Brown <[email-masked]>
Date: Wed, 10 Jun 2009 11:58:02 -0700

>determine anything more about the document I have to retrieve and
It would be useful to convey depth.  However, signaling the linked resource
contains inline markup is sufficient.

-Al

Al Brown

Office 714 327 3453
Mobile 714 263 6441

                                                                                                                                
                                                                                                                                
  Cc:         atom-syntax Syntax <[email-masked]>, "Nikunj R. Mehta" <[email-masked]>,                            
              [email-masked]                                                                                    
                                                                                                                                
  Date:       06/10/2009 11:40 AM

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Wed, 10 Jun 2009 12:05:23 -0700

On Jun 10, 2009, at 11:54 AM, Al Brown wrote:

> 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..
>
Signaling the use of in-lining extensions in Content-Type,  
atom:link@type, and app:accept could be done quite easily with James'  
proposed I-D.
>
> 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
> "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
>
> From:	
> Al Brown/Costa Mesa/IBM@IBMUS
> Cc:	
> James M Snell <[email-masked]>, atom-syntax Syntax <[email-masked] 
> >
> Date:	
> 06/10/2009 11:20 AM
> Subject:

---

From: Al Brown <[email-masked]>
Date: Wed, 10 Jun 2009 13:05:46 -0700

>Signaling the use of in-lining extensions in Content-Type, atom:link@type,
and app:accept could be done quite easily with James' proposed I-D.
Yes, provided either the inline I-D or profile I-D specified the value to
be used for the profile media type argument for atom documents with the
inline markup.  *shrug* Guess we have to wait to resolve this till the
profile I-D draft is available.

-Al

Al Brown

Office 714 327 3453
Mobile 714 263 6441

                                                                                                                                
                                                                                                                                
  Cc:         atom-syntax Syntax <[email-masked]>, James M Snell <[email-masked]>                                       
                                                                                                                                
  Date:       06/10/2009 12:07 PM                                                                                               

Signaling the use of in-lining extensions in Content-Type, atom:link@type,
and app:accept could be done quite easily with James' proposed I-D.

      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

      Office 714 327 3453
      Mobile 714 263 6441

 <ecblank.gi                                                  
 f>          "Nikunj R. Mehta" <[email-masked]>                   
 From:                                                                     
                                                                           
 <ecblank.gi                                                  
 f>          Al Brown/Costa Mesa/IBM@IBMUS                                 
 To:                                                                       
                                                                           
 <ecblank.gi                                                  
 f>          James M Snell <[email-masked]>, atom-syntax Syntax <       
 Cc:         [email-masked]>                                          
                                                                           
 <ecblank.gi                                                  
 f>          06/10/2009 11:20 AM                                           
 Date:                                                                     
                                                                           
 <ecblank.gi                                                  
 f>          Re: Sub-typing Atom documents                                 
 Subject:                                                                  

      Nikunj

      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-masked]
                  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.

                  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

                                                                           

                  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

                  > [1]
                  http://www.imc.org/atom-protocol/mail-archive/msg11398.html

                  > [2]
                  http://www.imc.org/atom-syntax/mail-archive/msg21114.html

                  > [4]
                  http://www.oasis-open.org/committees/download.php/32668

---

From: Joe Gregorio <[email-masked]>
Date: Thu, 11 Jun 2009 13:33:15 -0400

On Tue, Jun 9, 2009 at 6:24 PM, James M Snell<[email-masked]> wrote:
> 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:
>>
>> extension (whether blessed by IETF or not) to be present in accepted content
>> [1]. To illustrate the requirement by example, one would see:
>>
>> 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:
>>

-- 
Joe Gregorio        http://bitworking.org

---

From: [email-masked]
Date: Thu, 11 Jun 2009 17:37:54 +0000

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-masked]>

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

  Thanks,
   -joe

---

From: "Nikunj R. Mehta" <[email-masked]>
Date: Thu, 11 Jun 2009 10:43:16 -0700

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

On Jun 11, 2009, at 10:37 AM, [email-masked] 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
> Cc: Nikunj R. Mehta<[email-masked]>; atom-syntax Syntax<[email-masked] 
> >
>> profile to
>>> documents.
>>> type of
>>> requirement
>>> that an
>>> parameter and
>>> but it

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 11 Jun 2009 20:04:11 +0200

>will accept? That was the point of the service document which was to

Wasn't this the intent of the features draft?

What I like about the profile parameter is that it provides the opportunity to do a sort client side negotiation with a server that can serve up Atom in different varieties, such as:

<feed>
   <!-- ... -->
   <entry>
    <title>My Entry</title>
    <link rel="alternate" type='application/atom+xml; profile="http://example.org/profile/foo"' href="http://example.org/entries/1_foo.xml"/>
    <link rel="alternate" type='application/atom+xml; profile="http://example.org/profile/bar"' href="http://example.org/entries/1_bar.xml"/>
    <!-- ... -->
  </entry>
</feed>
    
The client could pick the variant it wants based on the profile.

Jan