[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Yucky Fragments
Marty.Schleiff@boeing.com;
CISSP
Associate
Technical Fellow - Cyber Identity Specialist
Computing Security
Infrastructure
(206)
679-5933
Marty, you said "The XRI is the identifier of the
resource,
NOT the address of the resource." I thought that was one of the big
selling points of XRI, the identifier is an address.
On fragments in
XRIs...I think they serve a purpose, but not one in resolution. The meaning of
fragments that I originally learned was that they were not for the server but
were an index into the representation(s) returned by the server. This
means they're not intended for use by the server, but by the consuming
application (the browser). The quote you gave from RFC3986 seems to
indicate the same thing.
For XDI we have the // syntax, though I think we
could define that better and do not know if that is in the current XRI
spec. For me // has always indicated a hierarchical index within the
representation returned by an XRI resolution. You could do away with # in favor
of //, but by keeping it you have both a hierarchical index (//) and a flat
index. IMHO though both are dealt with by the consuming application, and should
be ignored for the purpose of resolution.
Looking at WD 11 of the XRI
resolution spec, it seems to agree:
878 The fourth possible component of a
QXRI—a fragment—is by definition resolved locally relative
879 to the target
resource identified by the combination of the Authority, Path, and Query
880
components, and as such does not play a role in XRI
resolution.
Bill
-----Original Message-----
From: Schleiff,
Marty [mailto:marty.schleiff@boeing.com]
Sent:
Fri 9/14/2007 2:11 PM
To: xri@lists.oasis-open.org
Subject: [xri] Yucky
Fragments
Hi All,
Now that Drummond is working for Parity, he
doen't have as much time to
deal with my opinions. Too bad for the rest of
you, that means I now
have to pester you more.
I've never liked
fragments in XRIs; I think XRI should not allow
fragments.
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? Does each
fragment identify a piece of the
XRDS, or does it get tacked onto the back of
a service point URI, or get
tacked onto the back of every service point URI,
or what?
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?
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]