[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: A different perspective on * and / (long)
I realize I am in the minority in the perspective I'm sharing on the * vs. : issue. In the message below Peter adds his vote along with Gabe, Mike, Loren, and Dave to the preference to use both * and : as "second-level hierarchy characters", whereas I am advocating using just *. However after a conversation Dave and I had about this late yesterday, I woke up thinking about it at 4am this morning and came to a much deeper understanding of why there appears to be such a huge gap between these two perspectives. Since I couldn't get back to sleep, I'll try to explain it here. First, just to make it clear, I agree with everyone that if the choice is simply between the "readability" of the two examples given below, i.e.: xri:@:3*:4*:5/:6*:7 or xri:@:3:4:5/:6:7 ...then of course it appears to be a no-brainer. The latter is more compact and, as Peter says, "much easier to read". But therein lies the issue. What is "easier to read" depends on what you are reading for. What I realized laying in bed at 4am this morning is that I am reading for something entirely different. But to explain this requires explaining the entire worldview behind this perspective, and entire worldviews are not easy to explain, so please bear with me while I try. In this second worldview, * would not be considered a "secondary hierarchy character", but an "alternative hierarchy character" on an equal footing with slash. I can just hear Dave screaming right now, "What does Drummond mean, 'an "alternative hierarchy character" on an equal footing with slash'?? How could there be such a thing? Slash is THE 2396 hierarchy character! It defines 2396 segments. The only option we have is to define subsegments within slash segments!" But this is exactly what I mean about two entirely different worldviews. In the 2396 worldview the world is purely hierarchical. There is only slash because there is only hierarchy. It's pretty ironic, then, that URIs based on 2396 are the very basis of the World Wide Web, which is the very opposite of hierarchy. It's a peer-to-peer web. Any page can link to any page. Laying in bed at 4am, I did the following thought experiment, "Using conventional URIs, is there any way you can address the LINK between two web pages?" In other words, not the URI of Page A or the URI of Page B, but the LINK from Page A to Page B. Literally, the A tag present in the HTML of Page A that links to Page B. There is certainly no standard way, at least that I know of. So I started thinking through how you would do it. If Page A was expressed as XHTML, then the actual node of the XHTML document that contains the link to Page B would at least be addressable using an XPath expression under the URI of Page A. So you could have something like: http://www.example.com/Page-A#Xpath-to-A-tag-linking-Page-B Of course, there is no spec for doing this that I am aware of. However it wouldn't be hard to construct one. Since you know the link is in an A tag, you'd just need a standard XPath query that says, "Give me the A tag whose HREF attribute equals the following value" and then supply the target URI as a paremeter. Say this query was called "Xpath-A-ref". Then any site that supported this query could resolve a URI that looked like the following: http://www.example.com/Page-A?Xpath-A-ref&HREF="http://www.site.com/Page-B" Such an address would actually let you address Page B in the context of Page A. It lets you construct a path ACROSS pages, not just DOWN the DNS tree and local file path hierarchy to a specific page. Why would you want to be able to address across Web pages? If you wanted to be able to follow the path of who is linked to who. It lets you test assertions about relationships between pages. If the address above resolves, it tells you Page A is linked to Page B. If it doesn't, they aren't. Now, imagine if there was: a) a standard URI syntax character that equates to the link query operation "?x-path-A-ref" above, and b) a standard way in URI syntax to nest one URI inside another. Let's say the standard link query character was * and the nesting syntax was to enclose the nested URI in parentheses. Then the URI above could be expressed much more compactly and readably as: http://www.example.com/Page-A*(http://www.site.com/Page-B) Now let's take one more step. Say that the author of Page A had his own name for Page B inside the HREF tag that points to "http://www.site.com/Page-B". Say this name was "Glockenspiel". This is really a relative identifier for Page B, since it's relative to the Web page http://www.example.com/Page-A. But in the context of this Web page, it's very likely to be unique, since the author of Page A is unlikely to create two outgoing links to different resources on the same Web page and label both the A tags identically. In this case there is a second way to address the link between Page A and Page B using this relative identifier. This would look like: http://www.example.com/Page-A*(Glockenspiel) I know this example has been quite extensive, but as you can see, the point is that in this alternative worldview - this Web-based worldview - peer-to-peer linking relationships have an equal status with hierarchical relationships. Neither is "good" or "bad". Neither is "primary" or "secondary". They are simply equally valid. Like Cartesian and radian coordinate systems, they both let you address any point on a plane - it's just that each one can be much more appropriate for certain tasks. It follows then that in this worldview, the primary failing of 2396 syntax is that it does not accommodate the peer-to-peer linking worldview. It only accommodates the hierarchical worldview. It has no syntax for addressing link relationships, nor for nesting identifiers for this purpose (i.e., cross-references). In syntactic terms, it has only /, and no * nor (). Those of you who know me know why I am so passionate about this subject. To get from the Web to the Dataweb, we must be able to express the links between data and the links between data sharing authorities. Suddenly it is as important (if not more important) to be able to address the source of authority and permission in a data sharing relationship as it is to be able to address the data being shared. For example, look at the following sample XRI: xri:xri-A/(xri-B)*(/($contract)/this-contract/($v1))*(/(+email)/work/($v2)) (Note that the values "xri-A" and "xri-B" are placeholders for the actual XRIs for Authority A and Authority B, and "$contract" is the proposed XRI service dictionary identifier for XDI link contracts.) This is from a thread about potential XDI contract addressing available at http://wiki.idcommons.net/moin.cgi/DataSharing#head-0bd543034533c5641c0beacf 65be418a7a9c7fc5. Although this particular example is in the context of XDI (and uses only a proposed addressing syntax in that context), what I believe it illustrates is the tremendous importance, in that context, of link relationships. For example, this XRI expresses that authority A's relationship with authority B (xri-A/xri-B) is linked to a link contract from authority A (/($contract)/this-contract/($v1)) which is linked to a specific item of data from authority A (/(+email)/work/($v2)). So, in conclusion: * In the hierarchical-only worldview, / reigns supreme, and therefore the distinction between * and : as "secondary hierarchy" characters appears relatively minor. * In the combined hierarchy-and-peer-to-peer-link worldviews, / and * are equally important and equally valid first-level delimiters. / is used to express for hierarchical relationships between resources and * is used to express peer-to-peer linking relationships between resources. In this worldview, both "/:" and "*:" would be equally valid, as colon would always be used as the prefix for a persistent identifier. I believe this worldview is not unique to XDI. Although XDI architecture is fundamentally based on the ability to express links between resources, and it uses XRIs for this purpose, I believe that establishing the syntactic "equal footing" of * and / for the purpose of enabling the expression of peer-to-peer linking vs. hierarchical relationships could apply to many other uses of XRI beyond the scope of XDI. I hope this explanation helps bridge the gap between these two worldviews. =Drummond -----Original Message----- From: Peter C Davis [mailto:peter.davis@neustar.biz] Sent: Friday, June 11, 2004 5:45 AM To: Lindelsee, Mike Cc: xri@lists.oasis-open.org Subject: RE: [xri] RE: Single delegation character ditto. it is, among other things, much easier to read. --- peterd On Thu, 2004-06-10 at 17:56, Lindelsee, Mike wrote: > I also prefer the latter for the same reasons that Dave and Loren do. > > Mike > > -----Original Message----- > From: Dave McAlpin [mailto:Dave.McAlpin@epok.net] > Sent: Thursday, June 10, 2004 2:26 PM > To: Loren West; xri@lists.oasis-open.org > Subject: RE: [xri] RE: Single delegation character > > > Good point. Now that we've beaten the delegation issue to death, we can > come back to the original question about whether we should define one or > two second level delimiters. > > The question is whether we prefer > > xri:@:3*:4*:5/*:6*:7 > > or > > xri:@:3:4:5/:6:7 > > for reasons already stated. My preference is the second, i.e. to define > two second level separators, star ("*") and colon (":"). > > Dave >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]