[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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]