[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 concise. 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 understand). Here's a new question inspired by the examples in the previous messages. Are the following equivalent? $(http://example.com)=gmb @(http://example.com)=gmb =(http://example.com)=gmb +(http://example.com)=gmb 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 XRI > 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 XRI > authorities MAY assign XRIs #1A/B/C to the same resource, or #2A/B/C to > 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 declare > 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 > MUST treat > all delimiters as significant. Therefore synonymity between XRIs that > differ only in the delimiters used may only be established via local > policy or > resolution. > > =Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]