[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Yucky Fragments
I agree with Wil completely and appreciate the informed analysis. Back to the salt mines... > -----Original Message----- > From: Tan, William [mailto:William.Tan@neustar.biz] > Sent: Monday, September 17, 2007 1:41 PM > To: Schleiff, Marty > Cc: xri@lists.oasis-open.org > Subject: Re: [xri] Yucky Fragments > > Hi list, > > Sorry for coming to this thread late. I'm not sure I understand the > motivation behind it but comments below are my understand of XRI > fragments: > > Schleiff, Marty wrote: > > Do the following XRIs represent the same resource? > > > > @boeing*resource*abc#top > > @boeing*resource*abc#middle > > @boeing*resource*abc#bottom > > > > Do they return the same XRDS? > /If/ you resolve them, they will all yield the same resource. They > differ in that each address a different part of that resource. > > > Does each fragment identify a piece of the > > XRDS, > If the resolved resource is an XRDS document, then yes. > > And if the following document has any validity (it looks like just a > proposal at this stage), you could use XPointers to address contents of > the XRDS document. > http://www.w3.org/TR/xml-fragid/ > > > However, if you didn't need to resolve the identifiers, then they are > all different identifiers and they don't normalize to one another at > all. In fact, the only time any form of "normalization" is done is when > a key for cache storage and retrieval is needed. Because of the > resolution property that the #fragment does not affect the result of > resolution, clients can strip it out and use it as a cache key. > > > > or does it get tacked onto the back of a service point URI, > > Thanks for bringing this up, it made me think how the XRI resolution > model affects the use of fragments. > > In a way, yes. The client should resolve the identifier without the > fragment, and then apply the fragment to the resolved resource. > > If the client passes the fragment to the resolver, and the selected > service endpoint URI specifies an append value of "qxri" or "local", the > fragment could end up in the final constructed URI. > In the case of a local resolver, I guess it is up to the client (whether > to pass in the fragment). > In the case of a non-XRI aware browser, it will NOT pass the fragment to > the proxy resolver. Today, if you entered http://xri.net/=wil#foo into > the browser address bar, it will resolve the identifier without the > fragment, which will result in a 302 redirect to another URL. Depending > on which browser you use, that fragment either gets lost or gets tacked > onto the target of the 302. > > So, on IE you'd get > http://xri.dready.org/=wil > on Firefox you'd get to: > http://xri.dready.org/=wil#foo > > > > or get > > tacked onto the back of every service point URI, or what? > > > > Actually, yes it should be tacked onto any resulting URI from resolution. > > > > RFC3986 (spec for URI) says this about fragments: > > > > "The semantics of a fragment identifier are defined by the set of > > representations that might result from a retrieval action on the primary > > resource. The fragment's format and resolution is therefore dependent on > > the media type [RFC2046 </rfcs/rfc2046.html> ] of a potentially > > retrieved representation, even though such a retrieval is only performed > > if the URI is dereferenced." > > Does that mean the same fragment value might mean different things to a > > resource's various service end points supporting different media types? > > > > That's a good point, yes some media types may not support fragments, in > which case the fragment makes no difference. > > IMHO, fragments are useful in certain circumstances, and dropping it > would be seen as a feature degradation when compared to IRI/URI. > > =wil > > > > Marty.Schleiff@boeing.com; CISSP > > Associate Technical Fellow - Cyber Identity Specialist > > Computing Security Infrastructure > > (206) 679-5933 > > > > > > I did not miss your point. The XRI is the identifier of the resource, > > NOT the address of the resource. If anything, it's the address of the > > resource descriptor. The resource descriptor then may point to the > > address of the resource, including a fragment in the service point URI. > > > > If two resources are fragments of the same web page, then they should > > have separate XRIs (with no fragments) and separate XRDs with different > > service points. The service points URIs would be the same except for > > different fragments. > > > > Does the Resolution spec say to take the fragment from the XRI and > > append it to the service point URI? I doubt it and I hope not (but I > > don't know cuz I'm not working on Resolution). > > > > > > Marty.Schleiff@boeing.com; CISSP > > Associate Technical Fellow - Cyber Identity Specialist Computing > > Security Infrastructure > > (206) 679-5933 > > > > -----Original Message----- > > From: Drummond Reed [mailto:Drummond.Reed@parityinc.net] > > Sent: Friday, September 14, 2007 9:21 AM > > To: Schleiff, Marty > > Subject: RE: fragments > > > > I think you missed my point. The fragment isn't necessarily important to > > the XRI that identifies the target resource (via the target resource > > descriptor), it's important to the RESOURCE. The XRI, being the abstract > > address of the resource, needs to be able to "carry" the fragment for > > exactly the same reason that HTTP(S) URIs need to be able to carry the > > fragment: because some applications need to be able to address not just > > the resource but "inside" the resource. The fragment plays absolutely > > zero role in resolution and network processing of HTTP(S) URIs, but it > > plays a vital role in URI *addressing* of resources for this very > > reason. > > > > The same is true of XRIs. Net net: XRI can no more afford to drop > > fragments (or queries) than URIs can. > > > > ******** > > <ASIDE> Now that I'm working with Parity, it's like my whole life has > > been thrown into fast-forward. It's really intense. It's really good, > > because XRI and XDI are absolutely vital components of Parity's (and > > Higgins) work now, so we're getting loads and loads of daily hands-on > > feedback, and I think Higgins will have a huge impact on XRI and XDI > > adoption. > > > > The downside, if you look at it that way, is that I'm not going to have > > as much time to discuss XRI and XDI topics in the abstract -- which is > > what we have a lot of fun doing. It's not that I want to discourage > > exploration -- you have brought several breakthrough ideas to both XRI > > and XDI (your's and Laurie's critique of the XDI ATI model sparked the > > entire breakthrough to XDI RDF). But I'm going to be quicker to give you > > feedback if I think particular topic/exploration angle is or a dead-end. > > (I may be wrong, of course, but I'll be quicker to put a stake in the > > ground, just for efficiency's sake). > > > > This is one example. As much as it might appeal for aesthetic reasons -- > > I think fragments are ugly too -- from a legacy standpoint we're stuck > > with them. Secondly, the principal the XRI TC has followed is to > > maintain the highest possible compatability with URI architecture. > > > > Add those two together and my belief is the topic is a dead-end. If you > > feel strongly about this, by all means take the case to the TC list and > > see if you can find any support for it. > > > > I hope you understand -- I don't want to stifle innovation, but I also > > need to get enough sleep so I don't get a heart attack ;-) </ASIDE> > > > > Talk to you at 2PM. > > > > =Drummond > > > > > > > > > >> -----Original Message----- > >> From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] > >> Sent: Friday, September 14, 2007 8:36 AM > >> To: Drummond Reed > >> Subject: RE: fragments > >> > >> You said: "That's true at the XRI resolution level, yes. But that's > >> also true at the URI resolution level as well, i.e., with browsers and > >> > > URLs. > > > >> The place the fragment comes in is AFTER resolution, inside the > >> returned resource. That's where XRIs could use fragments just like > >> URIs. For example, if an XRI returned a web page, the fragment could > >> be used to address a fragment inside the page." > >> > >> I think this is hokey. XRI isn't supposed to return a web page (i.e., > >> a resource); rather, it returns the resource descriptor. If the > >> described resource is a web page, then the XRD might include a service > >> > > > > > >> point that includes a fragment, but the XRI should not include a > >> fragment. I don't think a fragment inside an XRDS page makes sense. > >> Unless maybe (and I don't like this) it's indicating a particular XRD > >> > > in an XRDS. > > > >> Marty.Schleiff@boeing.com; CISSP > >> Associate Technical Fellow - Cyber Identity Specialist Computing > >> Security Infrastructure > >> (206) 679-5933 > >> > >> -----Original Message----- > >> From: Drummond Reed [mailto:Drummond.Reed@parityinc.net] > >> Sent: Thursday, September 13, 2007 11:12 PM > >> To: Schleiff, Marty > >> Subject: RE: fragments > >> > >> Inline. > >> > >> > >>> -----Original Message----- > >>> From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] > >>> Sent: Thursday, September 13, 2007 8:33 AM > >>> To: Drummond Reed > >>> Subject: RE: fragments > >>> > >>> OK - query strings should stay. But fragments only add confusion. In > >>> > > > > > >>> the returned XRDS, I think the <query> (or something like that) > >>> shows the XRI being resolved. > >>> > >> Yes, it's the <Query> element. > >> > >> > >>> Would that include the fragment? > >>> > >> No. > >> > >> > >>> So the only > >>> difference in the returned XRDs's would be in the <query>? > >>> > >> Yes. > >> > >> > >>> If the > >>> fragment isn't included in the query, then I'd argue that the > >>> fragment > >>> > >>> is ignored, and the 3 example XRIs below are equivalent. > >>> > >> That's true at the XRI resolution level, yes. But that's also true at > >> the URI resolution level as well, i.e., with browsers and URLs. The > >> place the fragment comes in is AFTER resolution, inside the returned > >> resource. That's where XRIs could use fragments just like URIs. For > >> example, if an XRI returned a web page, the fragment could be used to > >> address a fragment inside the page. > >> > >> > >>> Does OpenID need a fragment on XRIs, or just on URIs? > >>> > >> If you're talking about the OpenID recycling issue, only HTTP(S) URIs. > >> We have a different way of solving the persistent identifier mapping > >> issue. > >> > >> =Drummond > >> > >> > >>> Marty.Schleiff@boeing.com; CISSP > >>> Associate Technical Fellow - Cyber Identity Specialist Computing > >>> Security Infrastructure > >>> (206) 679-5933 > >>> > >>> -----Original Message----- > >>> From: Drummond Reed [mailto:Drummond.Reed@parityinc.net] > >>> Sent: Wednesday, September 12, 2007 11:42 PM > >>> To: Schleiff, Marty > >>> Subject: RE: fragments > >>> > >>> Inline. > >>> > >>> > >>>> -----Original Message----- > >>>> From: Schleiff, Marty [mailto:marty.schleiff@boeing.com] > >>>> Sent: Wednesday, September 12, 2007 8:31 AM > >>>> To: Drummond Reed > >>>> Subject: fragments > >>>> > >>>> Hi Drummond, > >>>> > >>>> Do the following XRIs return the same XRDS? > >>>> > >>>> @boeing*resources*abc#top > >>>> @boeing*resources*abc#middle > >>>> @boeing*resources*abc#bottom > >>>> > >>> Yes. The reason ibecause s in HTTP, the fragment is ignored and only > >>> > > > > > >>> processed by the browser. > >>> > >>> > >>>> I suppose it's up to > >>>> @boeing*resources to figure that out. Do they represent the same > >>>> resource? I suppose that's also up to @boeing*resources. The bad > >>>> part is that there's no way for you (Drummond) to tell. > >>>> > >>> Correct. The decision of the OpenID editors to go with this solution > >>> > > > > > >>> for providing non-recyclable URLs was a hack. But they didn't have > >>> anything else, and they didn't want to force everyone to use XRIs > >>> ;-) > >>> > >>> > >>>> I still think XRI should NOT support fragments. I haven't thought > >>>> about it much, but I suspect I'd also favor dropping query > >>>> > > strings. > > > >>> Although I have long felt that fragments don't add much if anything > >>> to > >>> > >>> XRI, there was very strong consensus on the TC that we should > >>> maintain > >>> > >>> this compatability with IRI and URI. You could always try to > >>> convince them, but... > >>> > >>> As far as dropping query strings, I don't think that sell would even > >>> > > > > > >>> be possible. They are used for XRI resolution, XDI queries, etc. > >>> > > etc. > > > >> etc. > >> > >>> =Drummond > >>> > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]