RE: i0001: EPRs as identifiers (implementation model)

 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of David Booth
> Sent: 22 November 2004 05:02
> To: David Orchard
> Cc: Jonathan Marsh; public-ws-addressing@w3.org
> Subject: 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.  

As I think DaveO has mentioned elsewhere, this is no more ( or less ) of
an implementation choice than using;

 URIs with more than just a domain name
 URIs with query params

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

As mentioned above, it's only exposing as much as for example, the
following two sets of URIs expose:

Set 1

http://example1.org/
http://example2.org/

Set 2

http://example.org/1/
http://example.org/2/


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

Likewise

;-)

Gudge

> 
> 
> 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 15:10:58 UTC