Wil,
This problem is described in detail in
section 2.3.2 of the XRI Syntax 2.0 spec. IRIs (or other XRIs) that are
embedded as cross-references in an XRI will always need to be escaped so that
the cross-reference itself is not ambiguous.
For example, if the actual query string in
the XRI below…
xri://=foo*(xri://bar?baz=bar))
…is supposed to be “baz=bar)”
(not the closing paren is part of the query), then this MUST be escaped to…
xri://=foo*(xri://bar?baz=bar%29)
Again, see the rules at the end of section
2.3.2. (I imagine these were the ones not implemented in the OpenXRI parser yet
because they are, frankly, the tough ones!)
=Drummond
From: Tan, William
[mailto:]
Sent: Friday, June 09, 2006 3:49
AM
To: ;
Subject: [xri] iquery, ifragment
and xref
Hi folks,
Sorry for the cross posting. This is an issue that I
encountered in the OpenXRI parser and triggered by Harry’s test case that
the parser currently is not able to process:
xri://@example/(http://www.openxri.org/)
Looking at the above example, because the identifier within
the parenthesis above is an IRI, and the closing parenthesis “)” is
a legal character in an IRI, the parser doesn’t know when the IRI
terminates and consumes everything resulting in an IRI
“http://www.openxri.org/)” and leaves the cross reference open. Ok,
this is not the reason that the parser choked – it choked because IRI
cross references are simply not implemented but I’ve encountered another two
anomalies with the XRI syntax:
The ABNF for XRI uses IRI’s “iquery” and
“ifragment” which also boils down to “sub-delims”,
unlike XRI path-* productions which boil down to a much smaller
“xri-sub-delims”.
This means that the parser would not be able to
disambiguate:
xri://=foo*(xri://bar?baz=bar))
when the query in the embedded XRI reference is
“baz=bar)”.
I’m not sure if this has been discussed on the list
before..
=wil (http://xri.net/=wil)
