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 Tuesday, 4 December 2001 15:29:49 UTC