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] RE: XRI abstract syntax (was RE:Framing the 2.1 ABNF discussion -- the separation of abstract vs concrete syntaxes)

Steve, great message. [=Drummond] See inline below.

>Steven Churchill wrote:
>Drummond (and Wil),
>I think a change to the abstract syntax needs to be justified by the
>it provides to the "client" of that abstract syntax -- in this case the
>program/programmer using an XRI parser.

[=Drummond] Agreed.

>The abstract syntax is reflected in the data model of the syntax tree
>exposed by an XRI parser. [This is an important point. Please say so if you

[=Drummond] Agreed.

>The client of this syntax tree is the program/programmer who invoked the
>parser. In this sense, you are correct when you say below that a change to
>the abstract syntax will have an impact "on XRI resolution rules" because
>the XRI resolution algorithm is a client of the parser syntax tree.
>I have listed below again what I believe to be the current abstract syntax
>of XRI 2.0. I use your "prose" approach (a very good idea at this point)
>add a bit more detail.
>Abstract Syntax A (2.0):
>* An XRI is made up of one or more segments.
>* A segment is made up of zero or more subsegments.
>* A subsegment is a cross reference or a terminal.

[=Drummond] As I mentioned before, while this may be the abstract syntax we
were after, it didn't end out being what we captured in the 2.0 ABNF.

>* A terminal subsegment has a type: persistent or non-persistent.
>* A cross reference has a type: XRI, URI [, or whatever].
>* Oh yeah, and an XRI can have an optional query and/or fragment.
>I would submit that this abstract syntax accurately reflects the data model
>that is currently exposed by Wil's OpenXRI 2.0 resolver. Wil, please
>correct me if I am wrong here.
>Drummond, you seem to be proposing changing this abstract syntax to that of
>"Abstract Syntax B" shown below. This means that you are proposing changing
>the data model exposed in the XRI parser syntax tree.

[=Drummond] Yes.

>Abstract Syntax B (proposed for 2.1):
>* An XRI is made up of a sequence of one or more segments.
>* A segment may contain zero or more subsegments preceeded by an optional
>* A subsegment may be either a global reference or a local reference.  
>* A global reference may contain an optional value and zero or more local
>* A local reference may contain only an optional value.
>* A value may be either one or more characters or an encapsulated
>My question is: what benefit does the proposed Abstract Syntax B data model
>provide over Abstract Syntax A to the client of the parser's syntax tree?
>Does it provide new features or capabilities? (Or, does it just add

[=Drummond] Yes, it provides new features and capabilities.

1) It eliminates the need for the special 2.0 normalization rules around
optional stars. The TC unanimously decided this was a requirement for XRI
Syntax 2.1 last fall. See

2) It eliminates ambiguities about XRIs containing IRI authorities and
supports the clean new XRI forms ladder detailed at

3) It provides a new capability, global refs
(http://wiki.oasis-open.org/xri/XriCd02/GlobalRefs), that allows XRI authors
to compose global XRIs consisting of other global XRIs through direct
concatenation without the need to encapsulate the reference in parentheses.

>If we cannot identify a clear benefit, then I don't understand why we would
>want to change it.

[=Drummond] There are clear benefits. See above.

>Please understand, it *does not follow* that I am necessarily opposed to
>changing the concrete syntax (i.e., the ABNF) in order to provide
>readability. What I am opposed to is that the TC analysis does not make a
>clear distinction between the two things. 

[=Drummond] Steve, it frustrates me a little bit that in response to your
last message, I sent a very long and detailed analysis directed precisely at
answering this question. You must have read that message because you quoted
the abstract syntax above. How can you feel that "the TC analysis does not
make a clear distinction between the two things"?

>Again, I will restate how I would frame this discussion:
>o   Propose the abstract syntax for XRI 2.1. Discuss whether or not it
>differs from the abstract syntax of 2.0. If they are indeed different, then
>provide motivations (the requirements) for the changes.

[=Drummond] Done. See above.

>o   Provide motivations (the requirements) for why the 2.1 concrete syntax
>(reflected by the 2.1 ABNF) should have low or lower fidelity with the
>abstract syntax. Conceivably, these are around read and write-ability.
(Does the TC agree with these requirements?)

[=Drummond] I invite other members of the TC to provide their own answers to
this question, but I maintain the same position I took in the last message
-- when it comes to XRI, the ABNF *directly* reflects the abstract syntax.
ABNF is already a pure logic tree. That's why I think the proposed 2.1 ABNF
at http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1 now reflects the
proposed abstract syntax precisely.

>o   Provide some analysis of alternative concrete syntaxes (give some
>example XRIs) that may meet these requirements.
>o   Once the "look" of the concrete syntax is decided, then start
>discussing the nuances of the ABNF that will implement this concrete

[=Drummond] It follows from my answer above that I believe the only
difference between "alternative concrete syntaxes" will be the ABNF rule
names and rule ordering, i.e., cosmetics. The logic tree is the logic tree.
Once we as a TC agree on the underlying logic tree, I believe reaching
consensus on the rule names and order will be fairly easy.

[=Drummond] So, to summarize where I believe we are now as a TC with regards
to this issue:

1) We have a new proposed "abstract syntax" for XRI 2.1 that differs (as
describe above) from the abstract (and concrete) syntax of XRI 2.0. This
proposal is given in both prose and ABNF at

2) The motivations for why this new abstract syntax differs from XRI 2.0 are
described both in this message and on the Global Refs page at

3) Since this syntax is already abstract, and since the simplicity and
regularity of the syntax is already illustrated at
http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1, the first key question
we need to decide as a TC is whether we want to adopt this new abstract

4) Once we decide that, we can agree on the final rule names and rule
ordering in the ABNF.


>-----Original Message-----
>From: Drummond Reed 
>>Steve wrote:
>>Up through XRI Syntax 2.0, the concrete syntax--reflected in the 2.0
>>ABNF--has had a high degree of fidelity with the abstract syntax. For
>>example, the concrete syntax has explicit delimiters between the
>>subsegments, and cross references are delimited by surrounding parens.
>>that it did not have full fidelity, for example, because the first
>>subsegment delimiters could be omitted between a left-most GCS character
>>the next subsegment. That is a good thing.)
>Actually, Steve, I have come to believe it is a very bad thing. This
>seemingly small oversight has come back to bite us in the butt. See below
>for the reasons why.
>>I do not believe that anyone is proposing that 2.1 be a change the
>>*abstract* XRI syntax. However, because the TC has failed to frame the
>>discussion as such, it is difficult for me to tell.
>Yes, we are proposing a change to the abstract syntax, to fix exactly the
>problem above. See below.
>>XRI *does* have an abstract syntax. It is (essentially and informally):
>>XRI is made up of a sequence of segments, where each segment has zero or
>>more subsegments. Each subsegment can be either a terminal or a cross
>>reference." (Fragments, queries, persistence, and other minutiae have been
>>omitted in this description.)
>Unfortunately, when it comes to something as precise as ABNF for global
>identifiers, the devil is in the details. My personal belief is that it is
>in that minutiae that we glossed over a key issue in the 2.0 ABNF (the
>optional star), and my work on the 2.1 ABNF has given me progressively
>greater insight as to why that mistake is a much bigger deal than it looked
>like at the time. In fact it is exactly what you pointed out: ***because it
>means we got the abstract syntax wrong***!!
>The quickest way to explain this is to show what I believe the abstract
>syntax for XRI should be. Let's start with your explanation:
>"An XRI is made up of a sequence of segments, where each segment has zero
>more subsegments."
>As beautifully simple as that sounds, I believe it has one key problem that
>will become clear in the explanation that follows. But first let's look at
>the second half of your definition of the abstract syntax:
>"Each subsegment can be either a terminal or a cross reference."
>This is where the real problem starts. As much as I'd LIKE to agree with
>that, take a look at the following SIX different definitions of a
>(xri-subseg) in the 2.0 ABNF and tell me whether it's true or false:
>#1:	xri-subseg        = ( "*" / "!" ) (xref / *xri-pchar)
>#2:	xri-subseg-nc     = ( "*" / "!" ) (xref / *xri-pchar-nc)
>#3:	xri-subseg-od     = [ "*" / "!" ] (xref / *xri-pchar)
>#4:	xri-subseg-od-nz  = [ "*" / "!" ] (xref / 1*xri-pchar)
>#5:	xri-subseg-od-nx  = [ "*" / "!" ] 1*xri-pchar-nc
>#6:	xri-subseg-pt-nz  = "!" (xref / 1*xri-pchar)
>Of these, two (#3 and #4 )allow a subsegment to consist of a
>("xref" in the ABNF -- a paren-delimited string with no preceeding
>delimiter). However #1, #2, and #6 REQUIRE an xref to be preceeded by a
>delimiter. And one definition -- #5 -- doesn't even ALLOW an xref to be
>of a subsegment.
>Oops ;-)
>The one place where this highly convoluted set of rules (for which I am
>as culpable as anyone else on the 2.0 ABNF team ;-) falls down the most is
>in the issue of the optional star. A conversation with Les and Wil and
>on Monday helped me understand why.
>Since we WANTED the abstract syntax for XRI to be as simple as, "An XRI is
>series of zero-or-more segments, and each segment is a series of
>zero-or-more subsegments", but at the same time we NEEDED special rules
>about the first subsegment in a segment (and even MORE special rules for
>first subsegment of the authority segment), we approached the ABNF exactly
>that way: we made the abstract structure really simple and then wrote a
>whole bunch of special rules to *force* the concrete ABNF into the patterns
>we needed.
>And some of those special rules turned out to be so hairy that we decided
>not to even try to enforce them in the ABNF (because it would have gotten
>way too ugly), in particular the
>So when we started work on the 2.1 Syntax work, our first resolution was to
>get rid of the optional star character in the ABNF (this was before the
>proposal-formerly-known-as-compact-syntax even existed). As I looked at how
>to do that, I had to work out exactly what you suggested -- the REAL
>abstract syntax of XRI -- and the resulting ABNF ended out reflecting it
>First, let me state it in prose, as a series of bullet points:
>* An XRI is made up of a sequence of one or more segments.
>* A segment may contain zero or more subsegments preceeded by an optional
>* A subsegment may be either a global reference or a local reference.  
>* A global reference may contain an optional value and zero or more local
>* A local reference may contain only an optional value.
>* A value may be either one or more characters or an encapsulated
>Now, here's the same thing in ABNF (these rules are from
>http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1, only reordered to
>the abstract logic above):
>xri-hier-part     = xri-authority xri-path-abempty 
>xri-authority     = 1*global-ref
>xri-path-abempty  = *( "/" xri-segment )
>xri-segment       = [ ref-value ] *xri-subseg
>xri-subseg        = global-ref
>                  / local-ref
>global-ref        = gcs-char [ ref-value ] *local-ref
>local-ref         = lcs-char [ ref-value ]
>gcs-char          = "=" / "@" / "+" / "$"
>lcs-char          = "*" / "!"
>ref-value         = encap-ref
>                  / 1*xri-pchar
>encap-ref         = "(" encap-ref-value ")"
>encap-ref-value   = xri-reference
>                  / iri
>IMHO, the key difference in this abstract syntax vs. the 2.0 abstract
>is that it explicitly contains the notion of a *reference value*
>("ref-value" in the ABNF). A ref-value is NOT a subsegment. A subsegment is
>ALWAYS a delimiter followed by an optional ref-value. This is how we can
>cleanly differentiate between:
>	=example
>	=*example
>	=!example
>In the first case, we have a global reference whose ref-value is "example".
>In the second case, we have a global reference whose ref-value is EMTPY
>followed by a local reference of "*example", which is a reassignable
>reference to the ref-value of "example". In the third case, we have a
>reference whose ref-value is EMTPY followed by a local reference of
>"!example", which is a persistent reference to the ref-value of "example".
>The other key thing this syntax clears up is the role of an *encapsulated
>reference* ("encap-ref" in the ABNF, which is
>the-rule-formerly-known-as-xref). Under this syntax, an encap-ref is ALWAYS
>a ref-value.
>Lastly, to Gabe's point about how much of an impact this revised ABNF would
>have on XRI 2.0 installations. My answer: none. Every XRI that validates
>under 2.0 will validate under 2.1 with a single exception (see below). 2.1
>will allow XRIs that are not valid under 2.1 (specifically those that
>contain global-refs), but that's loosening the rules, not tightening the
>rules, so that should have no impact on currently deployed XRIs.
>The only exception is global XRIs assigned under the ! GCS symbol. As I
>discussed with Les, these XRIs now need to resolve under the @ space, i.e.,
>!!1003 needs to become @!!1003. Since !! XRIs have not yet been widely
>deployed, I am confident that we can deal smoothly with that one
>The only other impact is on XRI resolution rules. These can now be defined
>very precisely as described in the latter part of:
>	http://wiki.oasis-open.org/xri/XriCd02/GlobalRefs
>This impact should have no effect on existing deployed XRIs. Most
>importantly, since updates to the XDI.org GRS and OpenXRI code bases are
>currently waiting on us finishing XRI Resolution 2.0, and that is currently
>gated on closing on the 2.1 ABNF, closing on this ABNF is now our top
>priority. That's why it is a key subject of tomorrow's 10AM telecon (for
>which the agenda will go out shortly.)

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