OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xdi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xdi] Datapath addressing segment proposal


Addendum: in my earlier message I said I thought the way to implement this
proposal for non-restricted segment length in XDI XRIs was through adding
another subelement to the XRI element. I've played with that further and
don't think that's the way to go. 

Instead, this proposal is much better implemented through a simple
addressing rule: the third single slash in an XRI would represent the
"border" between the Instance level and the Data level. In other words, from
an XDI context, any XRI segments after the third single slash would resolve
internally to the Data node of the Resource being addressed by the first
three segments - the "body" of the contents of the data element - exactly
the way a URI fragment is resolved internal to the URI-addressable resource
that contains it.

To illustrate graphically, a URI fragment represents the border between a
distinct retrievable URI-addressable resource and a body of data that must
be addressed internal to that resource. 

	http://authority.com/foo/bar/baz/bing/bang#some-fragment

      <--------URI-addressable-resource-------->|<--internal-->

The rules in URI-land are that if you have a URI with a fragment, you only
retreive the URI-addressable resource, then you let the local application
resolve the fragment.

This proposal does exactly the same thing for an XDI resource, only at a
higher layer, because it still preserves the ability for resources UNDER an
XDI-addressable resource to be XRI- or URI-addressable resources (as well as
resources under THAT continuing to have fragments.)

	xri://authority/type/instance/foo/bar/baz/bing/bang#some-fragment

      <--XDI-addressable-resource->|<--XRI/URI-resource->|<--internal-->

So, as I put it to Victor a few weeks ago, here's one way to think about
XDI: 

* URI syntax standardized (Internet-wide) the first (authority) segment of a
global resource address and left the rest of the segments up to the local
systems.

* XRI syntax does the same thing, only adds more syntactic expressiveness.

* With XDI, we are actually standardizing the first THREE segments of a
global resource address, and now (with this proposal) leaving the rest of
the segments up to the local systems.

This dramatically increases the backwards compatability of XDI with existing
URI-addressable resources (Web pages, files, databases, etc.) In fact it
means XDI data interchange can be layered over any URI-addressable resource,
period. So the Dataweb can be a true superset of the Web.

=Drummond 

-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Wednesday, June 29, 2005 6:11 PM
To: xdi@lists.oasis-open.org
Subject: [xdi] Datapath addressing segment proposal

XDI TC Members and Observers,

In the agenda I sent out I said I would be posting a proposal to solve a
longstanding issue with regards to the XDI Addressing strawman, namely that
it it inherently restricted XDI XRIs to 3 slash-delimited segments. I was
going to do this by submitting an update to the current XDI Addressing
proposal (currently
http://www.oasis-open.org/committees/download.php/11437/draft-xdi-addressing
-v9.doc). However I didn't have enough time to do a full update.

Since the suggestion is really quite simple, for purposes of discussion on
tonight's call (if we have time for it), I'm just going to outline it in
this email.

Currently we only allowed three XRI subelements in the current XDI schema
(Authority, Type, and Instance). 

	xri://<authority>/<type>/<instance>


They can be delegated to any depth within each level, but it still
inherently restricts XDI XRIs to three levels. To use a slash INSIDE a level
means you must enclose it as an XRI cross-reference. For example, I can
include a slash in Type and Instance segments as follows:

	@foo*bar/(+email/Internet)/(+work/preferred)

But without going into query or fragment syntax, both of which have their
disadvantages for pure addressing, you can't go beyond three segments. So
there's no native way to address down "into the data".

This has always bothered me because XRIs can be used to address anything in
any hierarchical system to any depth (file systems, databases, ontologies,
etc.) and XDI shouldn't restrict this.

After a discussion with Victor, Andy, and Steve a few weeks ago, an obvious
solution occurred: allow a fourth XRI subelement that is used expressly for
addressing BELOW the XDI graph layer, i.e., "into the data", and which
itself can be repeated to any depth. In other words:

	xri://<authority>/<type>/<instance>/<data1>/<data2>/.../<datan>

The only special rule about this Datapath element is that because it is the
final element, if it contains slashes, its value does NOT need to be
enclosed as a cross-reference. That's how we allow it to be any depth.

We'll discuss further on the call.

=Drummond 







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]