Re: Possible new issue on interpretation of relative URI actors

The "resource" that might be dereferenced from the URI
could be a document containing the definition of the role
(in the case of SOAP-Env:actor) or it may be nothing more
than a name/identifier.

Note that it could also be used such that the "resource"
dereferenced could be the URI of the handler for that
block...

Cheers,

Chris


noah_mendelsohn@us.ibm.com wrote:

> 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 12:43:06 UTC