W3C home > Mailing lists > Public > xml-dist-app@w3.org > December 2001

Re: Possible new issue on interpretation of relative URI actors

From: Christopher Ferris <chris.ferris@sun.com>
Date: Wed, 05 Dec 2001 13:27:46 -0500
Message-ID: <3C0E6722.8040404@sun.com>
To: "Williams, Stuart" <skw@hplb.hpl.hp.com>
CC: Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, xml-dist-app@w3.org, Doug Davis <dug@us.ibm.com>
IMO they should be the *same* role. Seems to me that
at issue is whether or not the mechanism by which
a SOAP node determines which SOAP header blocks are
targeted at it is to register multiple "role"/handler
pairs (where the handler is the same thing) or whether
the SOAP node needs to normalize (is that the correct term
or is it absolutize?) the URI before use in resolving
against supported actor roles.

Cheers,

Chris

Williams, Stuart wrote:

> Hi Chris,
> 
> I had a slightly more subtle read of Noah's issue, in that I thought that he
> was asking where in fact two roles were being denoted by the use of a
> relative URI in an actor. ie does actor="#A" imply distinct roles "#A" and
> "http:/foo.org/#A" 
> 
> From Noah's message:
> 
>>>I am OK with drawing the conclusion that any node that acts in role #A 
>>>must (or should, if you prefer) act in some corresponding absolute URI 
>>>role as well.
>>>
> 
> The trailing "as well" is suggestive of an 'additional' role as opposed to
> "#A" and http://foo/#A" being different ways to denote the same single role.
> 
> Personally I'm a same single role kind of a person myself :-)
> 
> My 0.02,
> 
> Stuart
> 
> 
>>-----Original Message-----
>>From: Christopher Ferris [mailto:chris.ferris@sun.com]
>>Sent: 04 December 2001 21:47
>>To: Doug Davis
>>Cc: Noah Mendelsohn; Henrik Frystyk Nielsen; xml-dist-app@w3.org
>>Subject: Re: Possible new issue on interpretation of relative 
>>URI actors
>>
>>
>>I didn't interpret it that way. What I took away from
>>this is that the following are equivalent w/r/t the
>>actor role identified.
>>
>><S:Envelope xmlns:S="..." xml:base="http://foo/">
>>   <S:Header>
>>	<X:A S:actor="#bar" xmlns:X="...">
>>   </S:Header>
>>   <S:Body/>
>></S:Envelope>
>>
>><S:Envelope xmlns:S="...">
>>   <S:Header>
>>	<X:A S:actor="http://foo/#bar" xmlns:X="...">
>>   </S:Header>
>>   <S:Body/>
>></S:Envelope>
>>
>>
>>My $0.02,
>>
>>Chris
>>
>>Doug Davis wrote:
>>
>>
>>>Noah, are you suggesting that "http://foo/" and "http://foo/#A"
>>>should be equal w.r.t. determining roles?  I don't believe
>>>that are (or should be) equal.
>>>-Dug
>>>
>>>
>>>Noah Mendelsohn/CAM/Lotus@Lotus@w3.org on 12/04/2001 03:18:48 PM
>>>
>>>Sent by:  xml-dist-app-request@w3.org
>>>
>>>
>>>To:   "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
>>>cc:   Noah Mendelsohn/CAM/Lotus@Lotus, xml-dist-app@w3.org
>>>Subject:  RE: Possible new issue on interpretation of 
>>>
>>relative URI actors
>>
>>>
>>>
>>>No problem.  Although we use slightly different words, I think we are in
>>>general agreement.  URI's reference resources, by definition.  I am OK
>>>with drawing the conclusion that any node that acts in role #A must (or
>>>should, if you prefer) act in some corresponding absolute URI role as
>>>well.  A consequence of this decision is, for a given absolute AbsU, a
>>>node acting in #A and #B must act as either both AbsU#A and AbsU#B or
>>>neither.  I think we should call that out with at least a note.
>>>
>>>
>>>
>>--------------------------------------------------------------
>>----------
>>
>>>Noah Mendelsohn                                    Voice: 
>>>
>>1-617-693-4036
>>
>>>Lotus Development Corp.                            Fax: 
>>>
>>1-617-693-8676
>>
>>>One Rogers Street
>>>Cambridge, MA 02142
>>>
>>>
>>--------------------------------------------------------------
>>----------
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>"Henrik Frystyk Nielsen" <henrikn@microsoft.com>
>>>12/04/2001 01:05 PM
>>>
>>>
>>>        To:     <noah_mendelsohn@us.ibm.com>
>>>        cc:     <Noah_Mendelsohn@lotus.com>, <xml-dist-app@w3.org>
>>>        Subject:        RE: Possible new issue on interpretation of
>>>relative URI actors
>>>
>>>
>>>
>>>I apologize if my mail seemed a bit sharp in the language - I should
>>>have eaten something first.
>>>
>>>Henrik
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Henrik Frystyk Nielsen
>>>>Sent: Tuesday, December 04, 2001 09:12
>>>>To: 'noah_mendelsohn@us.ibm.com'
>>>>Cc: 'Noah_Mendelsohn@lotus.com'; 'xml-dist-app@w3.org'
>>>>Subject: RE: Possible new issue on interpretation of relative
>>>>URI actors
>>>>
>>>>
>>>>
>>>>In SOAP, all we use URIs for is as identifiers. A role is
>>>>identified by a URI which by definition identifies a resource.
>>>>We say nothing about what the semantics or properties of that
>>>>resource and I think this is very important that we don't do.
>>>>
>>>>When you pick a specific URI scheme (like for example HTTP),
>>>>you explicitly pick a URI space with certain naming
>>>>properties: whether it is hierarchical, whether it is
>>>>case-sensitive, etc. etc.
>>>>
>>>>One might know a suggested mechanism for dereferencing a URI
>>>>with a specific URI scheme may and if so then there is nothing
>>>>that prevents anybody from ever dereferencing a URI but that
>>>>is entirely outside the scope of SOAP.
>>>>
>>>>Dereferencing URIs is all about trust - I may trust DNS in
>>>>order to do so or I may trust somebody else to dereference it.
>>>>As such I don't agree that URI semantics is dangerous in
>>>>either of the cases you mention: it is a question of how I
>>>>establish trust in determining whether a Node can act in the
>>>>role that it claims it can.
>>>>
>>>>Henrik Frystyk Nielsen
>>>>mailto:henrikn@microsoft.com
>>>>
>>>>
>>>>
>>>>>-----Original Message-----
>>>>>From: noah_mendelsohn@us.ibm.com 
>>>>>
>>[mailto:noah_mendelsohn@us.ibm.com]
>>
>>>>>Sent: Tuesday, December 04, 2001 08:07
>>>>>To: Henrik Frystyk Nielsen
>>>>>Cc: Noah_Mendelsohn@lotus.com; xml-dist-app@w3.org
>>>>>Subject: RE: Possible new issue on interpretation of relative
>>>>>URI actors
>>>>>
>>>>>
>>>>>The question is not so much about establishing a base, it is about
>>>>>clarifying the responsibilities of a node in assuming a role.
>>>>>
>>>>>We have said nothing to indicate that a role is a web
>>>>>resource, or that it
>>>>>is the resource named by the actor URI.  For example, we do
>>>>>
>>>>>
>>>>nothing to
>>>>
>>>>
>>>>>preclude naming a role as the name of some other resource. 
>>>>>
>> Remember,
>>
>>>>>there may be a large number of intermediaries, possibly in 
>>>>>
>>different
>>
>>>>>organizations that might want to assume a role like:
>>>>>
>>>>>      http://example.org/cachemanagers
>>>>>
>>>>>Any resource referenced by the URI is not general at any of the
>>>>>intermediaries assuming the role, and it's almost surely not
>>>>>one accessed
>>>>>via http or that follows the rules for the HTTP scheme.  In
>>>>>that respect,
>>>>>one could argue that following the other rules for resources
>>>>>is dangerous
>>>>>as much as helpful.
>>>>>
>>>>>On the other hand, you might make the case that this is
>>>>>talking about some
>>>>>other resource, but that the assumed role itself is not the
>>>>>resource.  In
>>>>>other words, there's at least in principle a resource,
>>>>>probably at some
>>>>>nth+1st location, and the actor attribute is referring to that
>>>>>resource.
>>>>>In that case, I can see why we should follow the usual URI
>>>>>rules.  I think
>>>>>that's about where you and I would find common ground.
>>>>>
>>>>>In any case, I see it as subtle enough that we should indeed
>>>>>say something
>>>>>brief and clear about what's intended.  In other words, to say
>>>>>that roles
>>>>>are indeed web resources (from which follows everything I
>>>>>think you want
>>>>>wrt/ naming).  I'm OK with that.
>>>>>
>>>>>---------------------------------------------------------------
>>>>>---------
>>>>>Noah Mendelsohn                                    Voice:
>>>>>1-617-693-4036
>>>>>Lotus Development Corp.                            Fax: 
>>>>>
>>1-617-693-8676
>>
>>>>>One Rogers Street
>>>>>Cambridge, MA 02142
>>>>>---------------------------------------------------------------
>>>>>---------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>"Henrik Frystyk Nielsen" <henrikn@microsoft.com>
>>>>>12/04/01 10:54 AM
>>>>>
>>>>>
>>>>>      To:     <Noah_Mendelsohn@lotus.com>, <xml-dist-app@w3.org>
>>>>>      cc:
>>>>>      Subject:        RE: Possible new issue on
>>>>>interpretation of relative URI actors
>>>>>
>>>>>
>>>>>Please have a look at the proposed text for handling xml base
>>>>>which already discusses the question of how to establish a
>>>>>base URI for a message and how to deal with URIs in general.
>>>>>Given that we already have an issue for xml base I am
>>>>>wondering whether we need another issue.
>>>>>
>>>>>Henrik Frystyk Nielsen
>>>>>mailto:henrikn@microsoft.com
>>>>>
>>>>>[1] 
>>>>>
> http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0005.html
> 
>>>>
>>>>>In private discussion, Henrik and I tripped over the question of a
>>>>>relative URI used as an actor.  If a block has:
>>>>>
>>>>>      Actor="#A"
>>>>>
>>>>>or
>>>>>
>>>>>      Actor="A"
>>>>>
>>>>>and if a node decides to act in that role, is there necessarily some
>>>>>other absolute URI in which role it needs to act?  I had assumed
>>>>>
>>>>>
>>>>"no", but I
>>>>
>>>>
>>>>>think Henrik had assumed "yes", and he further believes that
>>>>>no changes to
>>>>>the SOAP spec are needed, as this is implicit in the web and URI
>>>>>architecture and the definition of a relative URI.
>>>>>
>>>>>I would prefer to at least be a bit clearer in the spec, say a bit
>>>>>more about what the base URI for a message might be, etc.
>>>>>Presumably the base
>>>>>URI must be stable through message processing, so if you no
>>>>>how to make #A
>>>>>absolute, then #B must follow from that and be handled consistently?
>>>>>
>>>>>All of this bears some relation to the dreaded Namespace
>>>>>
>>>>>
>>>issue (is it
>>>
>>>
>>>>>a string or a real URI) but at least in this case nobody is
>>>>>
>>>>>
>>>>proposing to
>>>>
>>>>
>>>>>actually retrieve a resource in most cases.
>>>>>
>>>>>Anyway, I recommend we open an issue.  Thanks.
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>>
>>
> 
Received on Wednesday, 5 December 2001 13:32:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 22:28:13 UTC