RE: [xri] Framing the 2.1 ABNF discussion -- the separation of abstract vs concrete syntaxes

["Chasen, Les" <les.chasen@neustar.biz>]

+1

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

> -----Original Message-----
> From: Gabe Wachob [mailto:gabe.wachob@amsoft.net]
> Sent: Wednesday, March 07, 2007 6:19 PM
> To: 'Steven Churchill'; xri@lists.oasis-open.org
> 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.
> 
> 	-Gabe
> 
> > -----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