RE: Possible Problems with an URI scheme?

Hey, thanks for the thoughts!
---


> Why not use XPath to traverse the children positionally?  This is very
> simple syntax -- for example, the <child4> element in your paper would
> be: exa://ROOT/2.1/3.1/4.3/5.1
> or in XPath: /*[1]/*[1]/*[1]/*[3]/*[1]
> or in abbreviated XPointer syntax:
> (http://www.w3.org/TR/2001/CR-xptr-20010911/#child-seqs)
> /1/1/1/3/1

XPath was considered, but it seems overly complicated and resource intensive for
my application.  (Furthermore, XPath is pretty complicated, at least for me!  :)
Anyway, the syntax (in the example you showed me), '/*', is not really
"JavaScript friendly" (or in C or C++ or Java or...).

I purposely stayed away from XPointer because I noticed it was a candidate
recommendation (and I know what happens to early [read: in the prehistory of the
rec.] implementations - like Netscape 4 and CSS, IE 5 and XSL, and so on).
However, XPointer seems pretty interesting and will probably consume a
significant number or two of my attention for the next couple of days. (see note
1.)
---


> Now, if you look more closely, you will notice that your exa: syntax has some
> redundant information.  Doesn't it seem interesting that the second path
> segment is prefixed by 2, the third by 3, and so on?  I bet you will find that
> the LN number always starts at two and increments by one.  So let's take a
> look at your syntax with the redundant data removed: exa://ROOT/1/1/3/1

I noticed that too.  However, I may need to extend the exa-URI (if I even use
it) to support relative URIs; the redundant LN can be useful to prevent the URI
from returning a set of possible node locations (instead of a specific node) -
contrast this to XPath or XPointer functions, which may return sets of
information in additional to individual points and positions.
---


> One slight thing we could do for consistency's sake could be to do something
> about the ROOT syntax.

I thought beginning every URI with 1.1 would be silly, but I think that
conflicts can result if I keep this notation and start using ids (as in XPath
Child Sequences).
---
---
Jimmy Cerra

(1) Despite my initial reactions, I decided to do some research on XPointer; I
read the CR and my XML book ("Learning XML", by Erik T. Ray) also has a section.
Although there is some contradictorily information - and this specific spec
seems draped in controversy (see: http://www.xml.com/pub/a/2001/11/07/id.html)
I think I might use it (or something like XPointer).
---


-----Original Message-----
From: Joshua Allen [mailto:joshuaa@microsoft.com]
Sent: Tuesday, April 23, 2002 1:20 AM
To: jimbofc@yahoo.com; uri@w3.org
Subject: RE: Possible Problems with an URI scheme?

Why not use XPath to traverse the children positionally?  This is very
simple syntax -- for example, the <child4> element in your paper would
be:

exa://ROOT/2.1/3.1/4.3/5.1

or in XPath:

/*[1]/*[1]/*[1]/*[3]/*[1]

or in abbreviated XPointer syntax:
(http://www.w3.org/TR/2001/CR-xptr-20010911/#child-seqs)

/1/1/1/3/1

Now, if you look more closely, you will notice that your exa: syntax has
some redundant information.  Doesn't it seem interesting that the second
path segment is prefixed by 2, the third by 3, and so on?  I bet you
will find that the LN number always starts at two and increments by one.
So let's take a look at your syntax with the redundant data removed:

exa://ROOT/1/1/3/1

Hmm, this is very interesting.  One slight thing we could do for
consistency's sake could be to do something about the ROOT syntax.
Since the root element will *always* have a LN of 1 and a SN of 1, the
syntax would be (putting back in the redundant information):

exa://1.1/2.1/3.1/4.3/5.1

Now let's take out the redundant information like we did before:

exa://1/1/1/3/1

Oops!  That is the exact same syntax as XPointer.  Now let's suppose we
are worried about what would happen if someone got confused and thought
the *name* of an element was "3" instead of the position.  We could make
it absolutely clear that we are referring to position instead of name by
using the position syntax of XPath:

exa://*[1]/*[1]/*[1]/*[3]/*[1]

Regards,

Joshua Allen
Microsoft WebData XML
425.705.7857

Received on Wednesday, 24 April 2002 01:35:43 UTC