- From: <noah_mendelsohn@us.ibm.com>
- Date: Tue, 4 Dec 2001 19:39:03 -0500
- To: dug@us.ibm.com
- Cc: chris.ferris@sun.com, henrikn@microsoft.com, xml-dist-app@w3.org
That's what I meant...Henrik had stronger feelings on this than I, indeed
my original position was that actor equality should be string equality. I
can see the case either way, and am personally OK with the requirement to
"absolutize" any relative URI.
------------------------------------------------------------------------
Noah Mendelsohn Voice: 1-617-693-4036
Lotus Development Corp. Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------------
Doug Davis/Raleigh/IBM@IBMUS
Sent by: xml-dist-app-request@w3.org
12/04/01 05:07 PM
To: Christopher Ferris <chris.ferris@sun.com>
cc: Noah Mendelsohn/CAM/Lotus@Lotus, Henrik Frystyk Nielsen
<henrikn@microsoft.com>, xml-dist-app@w3.org
Subject: Re: Possible new issue on interpretation of relative URI actors
Ah, if so, then ok.
-Dug
Christopher Ferris <chris.ferris@sun.com> on 12/04/2001 04:47:21 PM
To: Doug Davis/Raleigh/IBM@IBMUS
cc: Noah Mendelsohn/CAM/Lotus@Lotus, Henrik Frystyk Nielsen
<henrikn@microsoft.com>, 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 Tuesday, 4 December 2001 19:50:10 UTC