RE: i0001: EPRs as identifiers (implementation model)

Dave,

I certainly don't mean to mischaracterize anything.  Jonathan explained
that "[the subaddress is] used in conjunction with the address URI to
enable the infrastructure to deliver the message to its ultimate
destination".  I interpret that to mean that the infrastructure first
receives the message at the URI address, and then passes it on to the
ultimate destination further identified by the subaddress, where
"subaddress" presumably refers to the Ref Props/Params.  If so, that
sure sounds like a particular implementation model to me.  I don't know
how else you would characterize it.  

In other words, instead of presenting the client with an opaque
identifier, (which incidentally may be *internally* interpreted by the
service in whatever implementation-defined way it chooses), the use of
Ref Props/Params exposes that implementation model in the Web resource
identifier itself.  That doesn't sound like a good idea to me.

I hope that clarifies what I meant.  Please let me know if you think
I've misread something.


On Fri, 2004-11-19 at 13:23, David Orchard wrote: 
> OK, let's stop the mischaracterization.  Use of ref
> properties/parameters is *not* just an "implementation choice".  It is a
> choice in the sense of there is a choice, but it is the offering of the
> choice that we want.
> 
> If you want to go that way, I'll use the same argument against parts of
> URIs.  Use of Path vs Frag-ids vs query params is implementation
> dependent.  Let's pick one... I don't see the need for query parameters.
> I'd like URIs to remove Query parameters because it's just an
> implementation detail.



> Dave
> 
> > -----Original Message-----
> > From: David Booth [mailto:dbooth@w3.org]
> > Sent: Thursday, November 18, 2004 12:21 PM
> > To: Jonathan Marsh
> > Cc: David Orchard; public-ws-addressing@w3.org
> > Subject: RE: i0001: EPRs as identifiers (why XML?)
> > 
> > On Wed, 2004-11-17 at 15:09, Jonathan Marsh wrote:
> > > To add to DaveO's response, remember the purpose of the sub-address.
> > > It's used in conjunction with the address URI to enable the
> > > infrastructure to deliver the message to its ultimate destination.
> > 
> > That's a particular implementation choice.  It doesn't make sense
> > to design the spec around one particular imlementation model.
> > 
> > If the WG is contemplating such a fundamental departure from the
> > Web architecture as using EPRs instead of URIs as Web resource
> > identifiers, then there should be some very compelling
> > implementation-independent use cases that clearly demonstrate
> > the need.
> > 
> > > It's
> > > designed to work with SOAP, which defines headers for the purpose of
> > > delivering the message to the ultimate SOAP destination.
> > 
> > I guess this raises an important question: To what extent should
> > Addressing be tied to SOAP?
> > 
> > > SOAP headers
> > > are XML.  Thus it is quite natural for RefProps to be XML as well,
> to
> > > eliminate a translation or binding process from some other form
> (plain
> > > text?) to XML.  A model that wasn't SOAP-centric perhaps wouldn't
> get as
> > > much synergy from XML.
> > 
> > This is presupposing that RefProps are *necessary*.  Are they?  Please
> > show the use cases that demonstrate this need.
> > 
> > Without realistic use cases that clearly demonstrate the need,
> > RefProps look very much like an artifact of a particular
> > implementation model.
> > 
> > --
> > 
> > David Booth
> > W3C Fellow / Hewlett-Packard

-- 

David Booth
W3C Fellow / Hewlett-Packard

Received on Monday, 22 November 2004 05:02:20 UTC