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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


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


Gabe, you're correct that, for the XRI resolution, we still need to "add
semantics" to the two segment types, i.e. to define that within an XRI
authority segment, one of the two delimiters (slash) is the delimiter that
marks the end of the authority segment, and the other (star) is used for
subdelimiting authorities within the XRI authority segment.

The 1.0 BNF for this currently reads:

XRI-authority	= ( gcs-char [ xri-segment ] ) / xref-authority
gcs-char 	= "+" / "=" / "@" / "$" / "*" / "!"
xref-authority 	= xref  ( "." sub-segment / ":" sub-segment )
		*( "." sub-segment / ":" sub-segment )
xref 	= "(" ( xri-value / URI ) ")"

The revised BNF could read:

XRI-authority	= ( gcs-char [ authority-path ] ) / xref-authority
gcs-char 	= "+" / "=" / "@" / "$" / "!"
authority-path = [ ":" ] segment-value *( ( "*" ) [":"] segment-value )
xref-authority 	= xref  *( ( "*" ) [":"] segment-value )
xref 	= "(" ( xri-value / URI ) ")"
segment-value  = 1*xri-pchar / xref

I would stress, as Dave has said before, that the "semantics" of star being
the authority delegation character exists only in the context of the XRI
resolution spec. Otherwise star and slash are just two different segment
delimiters, and the semantics of what they mean in different XRIs ends out
being defined in specific contexts, such as the XRI authority resolution
context we're discussing here.

=Drummond 

-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Monday, June 14, 2004 9:46 AM
To: Drummond Reed; xri@lists.oasis-open.org
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]