A different perspective on * and / (long)

["Drummond Reed" <drummond.reed@cordance.net>]

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
>