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 17:07:56 UTC