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] Proposal for XRI Syntax 2.1 to treat all delimiters as signficant

Hi All,

Les, as I understand it Drummond's proposal is NOT to make the parens
optional. If there are parens present, then they were explicitly put
there for a reason (although I can't understand what such a reason would
be), and the XRI is NOT equivalent to a similar XRI without parens. So,
normalization would NOT remove any parens.

I don't favor the proposal. I want the use of parens to be more
intuitive, and the notion of parens being used to add clarity even if
they are not required is pretty intuitive to me. I still suggest that
several of the issues with the earlier "compact syntax" proposal would
not be issues at all if we limited the scope of compact syntax to a
single subsegment. Then "$(http://example.com)=gmb*sub1" would clearly
be equivalent to "$(http://example.com)*(=gmb)*sub1" and clearly NOT
equivalent to "$(http://example.com)*(=gmb*sub1)". This seems intuitive
to me, because it's more like the mathmatical concise interpretation of
parens (as opposed to the grammatical willy-nilly use of parens -- where
it's up to the author to determine if parens have the same meaning as
commas or hyphens -- or if some other punctuation should be used).
Identifiers are used to look up things, and looking things up requires
matching rules, and matching rules are frustrated by syntax that's not

I also don't like the new proposal's notion of an empty ref-value
because I can't comprehend what it means. It is certainly not intuitive
to me. I think the notion seems contrived and that it just exists to
make the syntax proposal work - not a very noble reason.

Sadly, I don't know how the older compact syntax proposal can do for the
XDI use case of double parens (which BTW is yet another use case I don't

Here's a new question inspired by the examples in the previous messages.
Are the following equivalent?


What determines which GCS to use? I think I'd favor having an xref
directly following a GCS character to be valid for only one of the GCS
characters (probably the $ or the +). Maybe if someone can explain the
differences to me I'd change my mind.

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Computing Security Infrastructure
(206) 679-5933

-----Original Message-----
From: Chasen, Les [mailto:les.chasen@neustar.biz] 
Sent: Monday, March 12, 2007 10:28 PM
To: Drummond Reed; xri@lists.oasis-open.org
Subject: RE: [xri] Proposal for XRI Syntax 2.1 to treat all delimiters
as signficant

I think this was meant to be a question to the TC.  If we are to make
()'s optional in cross references (or various refs as they are currently
being termed) should there be precedence or normalization rules such
that cross references without parenthesis are equivalent to cross
references with parenthesis.  For instance should these be the same?
	> #1A $(http://example.com)=gmb
	> #1B $(http://example.com)*(=gmb)
It seems to me that if we say that the second instance of a GCS
character is the start of a cross reference than it should be the same
as an explicit cross reference with ()'s.

contact: =les
sip: =les/(+phone)
chat: =les/skype/chat

> -----Original Message-----
> From: Drummond Reed [mailto:drummond.reed@cordance.net]
> Sent: Monday, March 12, 2007 2:50 AM
> To: xri@lists.oasis-open.org
> Subject: [xri] Proposal for XRI Syntax 2.1 to treat all delimiters as 
> signficant
> On the TC telecon last Thursday, I received the following action item:
> # DRUMMOND to send an email to the list summarizing a proposal that in
> Syntax 2.1 all delimiters and parentheses be considered syntactically 
> significant.
> The following examples were discussed on the telecon and are now
listed on
> the http://wiki.oasis-open.org/xri/XriCd02/GlobalRefs page.
> #1A $(http://example.com)=gmb
> #1B $(http://example.com)*(=gmb)
> #1C $(http://example.com)!(=gmb)
> #2A $(http://example.com)=gmb*sub1
> #2B $(http://example.com)*(=gmb*sub1)
> #2C $(http://example.com)!(=gmb*sub1)
> #3A $(http://example.com)*(=gmb)*sub1
> #3B $(http://example.com)*(=gmb)!sub1
> #4A $(http://example.com)*((=gmb))
> #4B $(http://example.com)*(((=gmb)))
> The essence of the proposal is that while it is very clear that many
> authorities MAY assign XRIs #1A/B/C to the same resource, or #2A/B/C
> the
> same resource, or #3A/B to the same resource, or #4A/B to the same 
> resource, it is also clear that SOME XRI authorities MAY NOT consider 
> these equivalent due to the additional metadata they contain.
> In other words, while SOME XRI authorites MAY declare these XRIs 
> synonymous by local policy in their own namespaces, other XRI 
> authorities may
> them as non-synonymous in their namespaces.
> In order to preserve the right of the latter set of XRI authorities to

> treat these XRIs as non-synonymous, the XRI Syntax 2.1 specification 
> all delimiters as significant. Therefore synonymity between XRIs that 
> differ only in the delimiters used may only be established via local 
> policy
> resolution.
> =Drummond

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