[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] A different perspective on * and / (long)
I'm not completely sure if you are proposing that we *change* XRI syntax to more directly support the concept of a link (we need a formal definition of this that includes use cases, IMHO), or if you are asking how the XRI TC might propose to formalize the concept of link *using* XRI syntax. The only thoughts that I have on this right now is that I would very much prefer to not change the XRI spec to include this concept directly and that it should be relatively straightforward for the XDI TC to formalize an XRI template that conveys the needed semantics for links. E.g., something like xri:<authority>/(linker-id)/(linkee-id) might be sufficient.
In any case, I'd appreciate clarification if this is a question that you see leading to a potential XRI spec change.
Mike
-----Original Message-----
From: Marc Le Maitre [mailto:marc.lemaitre@cordance.net]
Sent: Monday, June 14, 2004 10:29 AM
To: 'Dave McAlpin'; Wachob, Gabe; 'Drummond Reed';
xri@lists.oasis-open.org
Subject: RE: [xri] A different perspective on * and / (long)
Can I ask the question in a slightly different way?
Using and slightly reworking Drummond's words:
If there were a way of using conventional URIs, to address the LINK between
two web pages (not the URI of Page A or the URI of Page B, but the LINK from
Page A to Page B) would this be of value?
I'd really like to hear the group's thoughts on this question and then,
based on the answer, delve into how such a relationship might be manifested
in XRI syntax.
Marc
-----Original Message-----
From: Dave McAlpin [mailto:Dave.McAlpin@epok.net]
Sent: Monday, June 14, 2004 12:50 PM
To: Wachob, Gabe; Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] A different perspective on * and / (long)
Can you also talk about how this would affect resolution of relative
references, which currently depends on an unambiguous hierarchical
structure based on slash?
Dave
> -----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.
>
> 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
.
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]