- 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