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] Framing the 2.1 ABNF discussion -- the separation of abstract vs concrete syntaxes

Well put, Steve.

I'd also add also add consideration of the impact on existing
implementations and deployments of XRIs. This is what really worries me, in
addition to the fact that we're just now getting attention with OpenID and
we're considering changing the most visible part of XRI (the syntax). 

Personally, using ASN.1 for syntax seems scary for this purpose - and I
don't think it's the appropriate abstraction.  


> -----Original Message-----
> From: Steven Churchill [mailto:steven.churchill@xdi.org]
> Sent: Wednesday, March 07, 2007 3:01 PM
> To: xri@lists.oasis-open.org
> Subject: [xri] Framing the 2.1 ABNF discussion -- the separation of
> abstract vs concrete syntaxes
> All,
> It is to the TC's disadvantage that the discussion around the 2.1 ABNF has
> not been framed in terms of abstract vs. concrete syntaxes.
> XRI *does* have an abstract syntax. It is (essentially and informally):
> "an
> 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.)
> This abstract syntax is simple, elegant, and powerful. (It is, presumably,
> one reason that we are all in this space.)
> 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.
> (Note
> that it did not have full fidelity, for example, because the first
> subsegment delimiters could be omitted between a left-most GCS character
> and
> the next subsegment. That is a good thing.)
> Requirements of late have deemed that the concrete syntax should differ
> further from the abstract syntax, conceivably, because a fuller-fidelity
> concrete syntax is neither readable nor writable for common readers and
> writers of the concrete syntax.
> 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.
> I think that by framing this discussion improperly, the TC is wasting lots
> of time and effort. Here's how I would frame it:
> o   Propose the abstract syntax for XRI 2.1. Discuss whether or not it
> differs from the abstract syntax of 2.0.
> o   Provide motivations (the requirements) for why the 2.1 concrete syntax
> (reflected by the 2.1 ABNF) should have lower fidelity with the abstract
> syntax. Conceivably, these are around read and write-ability. (Does the TC
> agree with these requirements?)
> 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 syntax.
> For discussion around this "separation of abstract and concrete syntaxes",
> see section 1.2 of
> <http://www.cs.chalmers.se/~bringert/publ/exjobb/embedded-grammars.pdf> or
> <http://winnie.kuis.kyoto-u.ac.jp/foldoc/foldoc.cgi?abstract+syntax>
> Perhaps ASN.1 or something should be used to formalize the XRI abstract
> syntax.
> ~ Steve

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