I’m confused now. Section 2.3.2 says
“To avoid this type of misinterpretation, certain characters in a
cross-reference must be percent-encoded when transforming an XRI reference into
IRI-normal form.” This seems to be about the rules for an XRI reference
in IRI-normal form.
I’m talking about an XRI reference
in XRI normal form. If I would like to embed an XRI “xri://=foo/bar#baz”
in a cross reference to become:
xri://@example*(xri://=foo/bar#baz)
That is legal according to the XRI syntax,
but the parser (or rather the lexer component of) has a hard time recognizing
the final “)” as belonging to the enclosing cross reference because
when it encounters the “#”, it is consuming “ifragment”
characters, which expands out to *(ipchar / “/” / “?”) in
the syntax. Since “)” is part of “ipchar”, it could
belong to the fragment.
The workaround I’m doing right now
is to use xri-pchar instead of pchar in in iquery and ifragment, essentially
creating two new productions: xri-query and xri-fragment, which is at odds with
2.2.4 and 2.2.5.
=wil (http://xri.net/=wil)
From: Drummond Reed
[mailto:]
Sent: Saturday, June 10, 2006 5:36
AM
To: Tan,
William; ;
Subject: RE: [xri] iquery,
ifragment and xref
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)
