[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] A different perspective on * and / (long)
I hadn't realized this was the proposal. How would this affect XRI resolution? What marks the end of the ID Authority? If the two delimiters are *truly* equal, then it would seem that the first of either of them would mark the end of the authority, but that means that * couldn't be used as an authority delegation character. If the "/" still marks the end of the authority, then it seems a little odd since we're basically saying the two delimiters really aren't equivalent. Explain please ;-) -Gabe __________________________________________________ gwachob@visa.com Chief Systems Architect Technology Strategies and Standards Visa International Phone: +1.650.432.3696 Fax: +1.650.554.6817 > -----Original Message----- > From: Drummond Reed [mailto:drummond.reed@cordance.net] > Sent: Sunday, June 13, 2004 11:22 PM > To: xri@lists.oasis-open.org > Subject: RE: [xri] A different perspective on * and / (long) > > > That's a good one, Gabe - "failing to connect the dots" ;-) > > Anyway, to answer your question, the impact on the BNF is > that star would > now have an equal footing with slash. Either could be used to > delimit a > "segment", and either could be followed by a colon to denote > a persistent > segment (with the absence of a colon as the first character > of the segment > meaning the segment is reassignable). > > This is a significant simplification because "subsegments" go > away. Now > there would be just star segments and slash segments and they > would both > behave identically. The xri-segments production would become: > > xri-segments = [ ":" ] segment-value *( ( "/" / "*" ) [":"] > segment-value ) > segment-value = 1*xri-pchar / xref > > =Drummond > > -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Friday, June 11, 2004 10:19 AM > To: Drummond Reed; xri@lists.oasis-open.org > Subject: RE: [xri] A different perspective on * and / (long) > > Drummond- > Somewhere along the line, I'm failing to connect the > dots. While I > understand the idea that peer-links should be representable > in XRIs, and I > understand your proposal of using syntax to do this, I'm not > understanding > how this impacts the */: vs. *:/*. discussion.. > > -Gabe (who never admits to things he thinks about at 4am ;-) > > > __________________________________________________ > gwachob@visa.com > Chief Systems Architect > Technology Strategies and Standards > Visa International > Phone: +1.650.432.3696 Fax: +1.650.554.6817 > > > > -----Original Message----- > > From: Drummond Reed [mailto:drummond.reed@cordance.net] > > Sent: Friday, June 11, 2004 9:10 AM > > To: xri@lists.oasis-open.org > > Subject: [xri] 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.sit > > e.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-0bd5430345 > > 33c5641c0beacf > > 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 > > > > > > > > > > > > > To unsubscribe from this mailing list (and be removed from > > the roster of the OASIS TC), go to > > http://www.oasis-open.org/apps/org/workgroup/xri/members/leave > > _workgroup.php. > > > > > > To unsubscribe from this mailing list (and be removed from > the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]