Re: We need a EBNF spec

On Mon, 2006-01-09 at 07:46 +0100, Bjoern Hoehrmann wrote:
> Hi,
> 
>   I think W3C should publish a Recommendation or a Group Note defining
> the EBNF format "defined" in http://www.w3.org/TR/REC-xml/#sec-notation
> and elsewhere. This is needed because the definition in the XML 1.0
> Recommendation is incomplete and W3C technical reports define more and
> more variants of it for which it is not easy to tell whether they are
> different or not.

FYI, I have some related implementaiton experience to report.

There's a grammar in the SPARQL spec that follows the XML spec's
notation
  http://www.w3.org/TR/rdf-sparql-query/#grammar

Since important things deserve URIs*, we do readers the favor
of giving them the raw grammar, so they don't have to extract
it manually. (FYI, attached is a little XSLT ditty for
extracting the XML grammar from the XML version of the XML spec).
  http://www.w3.org/TR/rdf-sparql-query/parsers/sparql.bnf

And not only does the whole grammar deserve a URI, but the
symbols in the grammar. So we publish the grammar itself
in RDF/XML (and turtle):

 http://www.w3.org/TR/rdf-sparql-query/parsers/sparql.rdf
 http://www.w3.org/TR/rdf-sparql-query/parsers/sparql.ttl

The RDF vocabulary I used for modelling EBNF is a work-in-progress.
I wrote a little bit about it a couple weeks ago...

 bnf2turtle -- write a turtle version of an EBNF grammar
 http://dig.csail.mit.edu/breadcrumbs/node/85


TimBL used a similar RDF vocabulary to specify N3
 http://www.w3.org/2000/10/swap/grammar/n3-report.html
 http://www.w3.org/2000/10/swap/grammar/n3.n3
 <- http://www.w3.org/DesignIssues/Notation3

We're in discussion about working out the differences between our
grammars.

We're making slow progress on it. Anybody who wants to help it
go a little faster will please contact me.


* http://www.w3.org/TR/webarch/#pr-use-uris


> For example, the XML 1.0 Recommendation does not define whether a symbol
> like "Clock-value" may be used; on the right hand side this might be
> interpreted as Clock - value, so maybe not, but e.g. SMIL 2.1 uses this
> syntax. The result is that some EBNF parsers don't accept the grammars
> in SMIL 2.1, which is bad.

Let's see...
http://www.w3.org/TR/SMIL/smil-timing.html#Timing-TimingAttributeGrammars

Indeed, my code doesn't grok '-'s in symbols. I just used \w+

    elif s[0].isalpha():
        i = re.match("\w+", s).end(0)
        return (('id', s[:i]), s[i:])

>  The lack of good parsers then leads to having
> no means to verify grammars in technical reports, so the other errors in
> the SMIL 2.1 grammars are even harder to find.


> 
> Some technical reports like http://www.w3.org/TR/xpath20/#id-grammar
> also modify certain aspects of EBNF and/or include certain parts of the
> original EBNF "specification" which makes it even harder to recognize
> whether EBNF in one technical report can be processed just like EBNF in
> some other specification, you have to study the details first to do
> that.
> 
> Some technical reports like http://www.w3.org/TR/2005/WD-its-20051122/
> and http://www.w3.org/TR/2005/WD-emma-20050916/ then use ::= grammars
> without defining the format at all (and in case of EMMA it's not EBNF
> as defined in XML 1.0...) and yet other technical reports refer to EBNF
> http://www.w3.org/TR/2005/WD-SVGMobile12-20051207/paths.html#PathDataBNF
> as defined in XML 1.0 but the grammar does not actually use it, and some
> like http://www.w3.org/TR/2005/WD-P3P11-20050701/ don't even use EBNF or
> another standard format, but invent new variants of other formats.
> 
> Most of this is better though than the usual handwaving reference to
> some vague terms to define certain lexical constraints.
> 
> I think that a complete stand-alone reference for this format will
> encourage more working groups to make use of it rather than no formal
> grammar or some other format instead, encourage to make normative
> reference to it rather than copy and paste some extended subsets across
> multiple technical reports, encourage tool development around EBNF which
> will then help to verify the technical reports, which in turn further
> encourages making use of it. It will also help me to introduce {min,max}
> quantifiers into EBNF.
> 
> Writing the specification should be an easy mostly copy'n'paste job.

Umm... the variance you cite above suggests eactly the opposite;
it suggests that getting consensus on an EBNF spec will be quite
challenging.

> Thanks,
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E