Subject: RE: Private extension support (was Re: Q: Put request should return Atom entry?

From: "David Orchard" <[email-masked]>
Date: Tue, 27 Jul 2004 16:50:25 -0700

I want to clearly understand the issue that you are talking about.  I'm
not sure what you mean by protocol extensibility, because the example
you gave seemed like format extensibility

There are 2 different types of extensions that I see:
1. An extension to the protocol is done, ie a new method is added.
2. An extension to the format is done.

In the case of an extension to the format, I think we are mostly covered
if we follow the things I wrote up on the extensibility/versioning pace.
I agree that we could use SOAP to take advantage of header/body
separation and role, mustUnderstand adornment.  One solution is that
application extensions could be done as soap headers marked with mU.

IMO, the Web services folks are really hamstrung on the issue of
application extensions.  OOH, the movement has been to basically not
allow or define application extensions in headers.  I had to fight like
a demon to get the Application Data feature into WSDL 2.0 (basically
optional/mandatory headers), and I still think it's a deficient feature
and probably won't get supported by the big cos.  OTOH, folks from the
big cos have regularly said that soap provides a mustUnderstand model
for mandatory extensions.  Trying to reconcile these positions leaves
you where application extensions are done as soap headers but not
described in wsdl.  And here I thought WS was about contracts and
interface specifications.

So, I think that a mustUnderstand in the application level is just
right, because then we can control and model the schema the way we want.
And there's no weird modeling to get it into the format aspects of soap.

I also think that the "protocol" aspect of soap really kills the ability
to use it as a RESTful format.  For example, soap 1.2 prohibits PUT and
DELETE as part of the soap-response MEP.  So Atom would have to invent a
new SOAP 1.2 mep.  gak!

On an extension to the protocol, I don't know how SOAP helps us.  Are
you talking about a 3rd party wanting to do a new verb and possibly mark
it as mU?  But I argued you want to fail as early as possible, which
could only be done with Mark's profile idea.

Ie, you don't want to fail when you get the message, you want to fail
earlier.  

Dave 

-----Original Message-----
From: Mark Baker [mailto:[email-masked]] 
Sent: Monday, July 19, 2004 7:31 PM
To: David Orchard
Cc: Atom Syntax
Subject: Re: Private extension support (was Re: Q: Put request should
return Atom entry?

On Mon, Jul 19, 2004 at 09:49:49AM -0700, David Orchard wrote:
> I wrote up some thoughts a while ago on applying some "standard"
format extensibility rules to protocols
http://www.pacificspirit.com/blog/2004/06/14/protocol_extensibility_and_
versioning

Right-o.

> Seems like a reasonable question to ask, but it's harder to figure out
what to do...

As I see it, we have three options, at least to begin with;

1. support (RESTful) SOAP
2. support RFC 2774
3. forget about it

With both #1 and #2, my plan is that vanilla HTTP would be used by
agents not implementing an incompatible extension.  For agents that do
support such an extension, we'd recommend that the extension be defined
using whichever one of those options we decide upon.  Where it gets
tricky is that we'd also need to define behaviour for agents that choose
not to support either option (since to support one is a significant
burden with no immediate payback) so that their behaviour is
consistent with that of an agent which does support it, but no
extensions.  For example, if we opted to use SOAP, then an Atom server
choosing not to support it would still need to be able to respond with a
SOAP mustUnderstand fault to all incoming SOAP requests (as we're
assuming that SOAP is only used when mustUnderstand is used, though
there's some wiggle room there we can play with).

FWIW, I'd personally like to see SOAP supported since extensibility is
what it's best at, and, unlike RFC 2774, actually has a deployed SDK or
two. 8-)

I'd be happy to spend the time writing a Pace on this - I just wanted to
get a feel from folks about whether that would be a waste of my time or
not.  Obviously I'd be looking directly to you, Dave, for support and
input because I believe you appreciate the importance and complexity of
this space.

Mark.

---

From: Mark Baker <[email-masked]>
Date: Tue, 27 Jul 2004 23:00:20 -0400

> you gave seemed like format extensibility

Sorry if I wasn't clear, but I definitely intended to refer to protocol
extensibility.  Specifically, how does one go about adding a new header
when using the Atom "API"?

> DELETE as part of the soap-response MEP.  So Atom would have to invent a

I think PUT would be covered with the req/resp MEP, but you're right
about DELETE.  But is adding a new MEP such a big deal?  I dunno.  I
haven't looked at any SOAP 1.2 tools to see how they handle (or not)
extension MEPs.

> it as mU?

Actually, I was just thinking about extension headers, not methods,
(since extension methods are already effectively mU in HTTP).  i.e. if
you wanted to add a non-mU header you could do so as an HTTP header, but
if you wanted to add an mU one, you'd do it with SOAP.  SOAP helps us by
adding mU to HTTP, effectively.

Anyhow, I'm obviously not going to stand up screaming for this, since
I'd personally be happy to see SOAP not used in Atom.  I just felt that
this was one option around which concensus could form.

>  But I argued you want to fail as early as possible, which

You mean when your spidey sense is tingling? 8-)

But seriously, for adhoc integration, when there's no prior agreement
between parties, I don't think there is anything earlier than "when you
get the message".

Mark.

---

From: Ken MacLeod <[email-masked]>
Date: 27 Jul 2004 22:23:02 -0500

> 2. An extension to the format is done.

This is probably obvious to the point of being mundane, but the
simplest forms of extensions to the protocol will be in the area of
endpoints (collections of resources in a URL-space or active
endpoints, like searches) and more Atom-inspired resource types
(configuration, blogrolls, users, FOAF).

This is all basic REST but nevertheless should be mentioned and
recommended as routes of extensibility for Atom because people often
forget it's there -- kinda like breathing.

  -- Ken

---

From: Sam Ruby <[email-masked]>
Date: Wed, 28 Jul 2004 07:12:31 -0400

> forget it's there -- kinda like breathing.

IMHO, this argument is strenghtened if we keep:

   <atom:link href="..." type="..."/>

And weakened if every unique resource type needs a new and unique 
extension to the format.

- Sam Ruby

---

From: Ken MacLeod <[email-masked]>
Date: 28 Jul 2004 09:54:44 -0500

Sam Ruby <[email-masked]> writes:

> > simplest forms of extensions to the protocol will be in the area
> > of endpoints (collections of resources in a URL-space or active
> > (configuration, blogrolls, users, FOAF).  This is all basic REST
> > but nevertheless should be mentioned and recommended as routes of
> > extensibility for Atom because people often forget it's there --
> > kinda like breathing.
> 

Yes, that's why having a relation name (whereever it goes) declaring a
resource type is a bad idea.

However, that shouldn't be confused with having a unique relation name
(whereever it goes) for indicating *why* you would want to traverse a
link (regardless of or only secondarily dependent on the resource type
at the other end of the link).

Every new relation name (wherever it goes) is going to be a new and
unique extension to the format.

Dave Orchard's PaceExtensibilityAndVersioning is recommending XML
qnames as attribute values for those relation names, and whereas I
prefer not to have qnames in content I believe that approach is better
than the other suggested alternatives for @rel.

What is really less than optimal is having URI references appear in
"odd places", like other attributes (@uri) or element content (<id>,
<uri>), without an extensibility model for locating them there.
Extensions will follow the pattern set by the core and Atom processors
will not be able to apply rules, like xml:base, to those URI
references in new, odd places.

  -- Ken

---

From: Dare Obasanjo <[email-masked]>
Date: Wed, 28 Jul 2004 08:56:58 -0700 (PDT)

> And weakened if every unique resource type needs a

Surely you mean 

  <atom:service href="..." />

or whatever that Pace became?

=====
THINGS TO DO IF I BECOME AN EVIL OVERLORD #25
No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot.

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

---

From: Sam Ruby <[email-masked]>
Date: Wed, 28 Jul 2004 12:25:33 -0400

Dare Obasanjo wrote:
>>>This is probably obvious to the point of being
>>
>>mundane, but the
>>
>>>simplest forms of extensions to the protocol will
>>
>>be in the area of
>>
>>>endpoints (collections of resources in a URL-space
>>
>>or active
>>
>>>endpoints, like searches) and more Atom-inspired
>>
>>resource types
>>
>>>This is all basic REST but nevertheless should be
>>
>>mentioned and
>>
>>>recommended as routes of extensibility for Atom
>>
>>because people often
>>

No, I mean atom:link as described in 
http://www.imc.org/atom-syntax/mail-archive/msg07382.html

- Sam Ruby