OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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:William.Tan@neustar.biz]
Sent: Friday, June 09, 2006 3:49 AM
To: xri@lists.oasis-open.org; openxri-users@lists.sourceforge.net
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)

 

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]