RE: [xri] Yucky Fragments

["Gabe Wachob" <gabe.wachob@amsoft.net>]

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
> >>>
> >
> >
> >