W3C home > Mailing lists > Public > www-qa@w3.org > February 2006

Re: We need a EBNF spec

From: Dan Connolly <connolly@w3.org>
Date: Wed, 22 Feb 2006 09:03:09 -0600
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: spec-prod@w3.org, www-qa@w3.org
Message-Id: <1140620589.26363.657.camel@dirk.w3.org>
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

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).

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):


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

TimBL used a similar RDF vocabulary to specify N3
 <- http://www.w3.org/DesignIssues/Notation3

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

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...

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

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

Received on Wednesday, 22 February 2006 15:03:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:37 UTC