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