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 /


Based on your feedback maybe I should have asked the question slightly
differently:

Q: Is there value (independent of the ability to identify Resource A and
Resource B) in being able to express the relationship (link might be a
weaker way of saying the same) between A and B so that we are able, through
the core advantages of XRIs, to address the source of authority and
permission in a data sharing relationship in the same way we are able to
address the data being shared?

I don't know the impact on the XRI scheme of enabling such a capability and
whether it is too major to be addressable in the next revision we propose. I
just wanted to consider the value before delving into the "how we might do
it" discussion.

Marc



-----Original Message-----
From: Wachob, Gabe [mailto:gwachob@visa.com] 
Sent: Monday, June 14, 2004 1:46 PM
To: marc.lemaitre@cordance.net; Dave McAlpin; Drummond Reed;
xri@lists.oasis-open.org
Subject: RE: [xri] A different perspective on * and / (long)

You are asking about reifying the *link*, which is a totally appropriate and
relevant question.

I'm not sure this is strictly an XRI issue. It really has to do with a) what
type of document the link appears in, and b) what do we mean by a link.

There are many different types of links. HTML <a href> tags are one kind.
XLINK elements are another. One could argue that URI references in RDF are
links. One could argue that XDI contracts are links. And I've only talked
about XML documents - what about "links" in non-XML formats? 

So I don't know that there is a general answer. At least not without a
general definition of a "link". 

One more thing - if you are talking about the link, then simply using the
URI that is the *target* of the link (ie the place being pointed to) is not
really a good idea. Concretely, if I have document A, which contains link L
pointing to document T, then I don't want to refer to L using any part of
T's identifier. This is because if T's identifier changes, L's value perhaps
would change (perhaps not), and I still want to be able to refer to the
*link*, no matter what it changes to. 

If we limited ourselves to identifying XML elements as links (that is,
assume a "link" correlates to a specific XML element), then the process of
identifying a "link" is no more complicated than identifying an XML element,
for which there are at least a couple of ways: ID attributes (xml:id or
other), XPATH, or some custom attribute... all of which can be used to
construct an XRI (using # fragment notation, for example). 

	-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: 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
> .
> 
> 




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