[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] iquery, ifragment and xref
|
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. From: Drummond Reed
[mailto:drummond.reed@cordance.net] 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: 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) |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]