[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [Openxri-users] [xri] iquery, ifragment and xref
|
That definitely needs to be clarified in
the spec, or in a –bis version of it. For one, if you are going to escape “)”
and “(“ in an embedded cross reference in XRI normal form, you’d
need to also escape “%”. This gets ugly very quickly if you have an
escaped XRI reference that gets transformed to URI-normal form, because what
started out as an innocent “)” gets transformed into %29 in
XRI-normal form, which then morphs into “%2529” in IRI normal form. I would much prefer to disallow parentheses
in XRI query and fragment ABNF, i.e. create a separate xri-query and
xri-fragment production instead of re-using iquery and ifragment. From: Drummond Reed
[mailto:drummond.reed@cordance.net] Wil and Harry, Sorry for my delay on responding; lots
going on as we work up to getting the XRI GRS launched next week. Harry’s right – I didn’t
understand the full extent of what Wil was originally asking. Wil, I think the disconnect
is that there is an inherent assumption in XRI syntax that XRI parsers
understand cross-references. To take your example:
xri://@example*(xri://=foo/bar#baz) An XRI parser should not have any problem
understanding the embedded cross-reference “(xri://=foo/bar#baz)”,
even though it contains a pound sign, because as soon as it sees the opening
paren “(“, it should know this is the start of a cross-reference
and it should ignore any other character between it and the closing paren
“)”. In other words, to an XRI parser, the XRI should effectively
be as transparent as:
xri://@example*(xxxxxxxxxxxxxxxxxx) I am pretty sure that Epok said that the
XRI parser they originally contributed did not “do”
cross-references completely, and maybe that’s what you are now
discovering. So for an XRI in XRI-normal form,
“xri://@example*(xri://=foo/bar#baz)” does not require any
escaping. The embedded cross-reference only requires escaping in conversion to
IRI-normal form. However the following XRI *does*
require escaping even in XRI-normal form in order for the full cross-reference
(which is meant to include “)foo”) to not be ambiguous:
xri://@example*(xri://=foo/bar#baz)foo) must be escaped
to…
xri://@example*(xri://=foo/bar#baz%29foo) Hope this helps, =Drummond From: Dirty Harry
[mailto:dirty-harry@users.sourceforge.net] Hello everybody I agree with Wil, that it's not section
2.3.2 we can apply to the given problem. But section 2.2.2 says “It is important that the value of a cross-reference
be syntactically unambiguous, whether it is an absolute IRI or one of the
various forms of an XRI reference”. Maybe this
sentence implies the escaping requirement mentionned by Drummond. Regards Harry From:
openxri-users-bounces@lists.sourceforge.net
[mailto:openxri-users-bounces@lists.sourceforge.net] On Behalf Of 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: 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]