RE: [xri] A different perspective on * and / (long)

["Wachob, Gabe" <gwachob@visa.com>]

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.