sbnf (striped BNF)

I've been trying to figure out how to simplify our syntax situation.

I had thought, in November, when I suggested using asn06, that it would
help, but I don't see that happening.  What I'm thinking now is to
have the master grammar be the presentation-syntax BNF, but to make sure
the BNF is written in a style such that we can derive the abstract
syntax from it, for use in generating UML-like diagrams, the XML syntax,
and (in general) the object model.

To do that, the BNF has to be striped, to have property (role, slot)
names.  For example, where the current BLD draft says this:

[1]   Implies  ::= ATOMIC ':-' CONDITION

we need some way to say what the associated property names are.  If we
wanted to be verbose about it and stick with normal BNF, we would write
this:

[2]   Implies ::= then ':-' if
      then ::= ATOMIC
      if ::= CONDITION

That gets pretty tedious pretty quickly, so I suggest we use an "in-line
production" syntax, like this:

[3]   Implies ::= then::ATOMIC ':-' if::CONDITION

The idea here is that the "::" infix operator in BNF is syntactic sugar
for making another production.  Forms [2] and [3] are just about
semantically equivalent.  I'm pretty sure we want them to be not quite
equivalent, though, in that I think in form [3] the property names
should be local -- scoped to "Implies" -- so that grammatically it's
really equivalent to this:

[4]   Implies ::= Implies__then ':-' Implies__if
      Implies__then ::= ATOMIC
      Implies__if ::= CONDITION

This allows us to have things like, where the property "name" is shared:

   Variable ::= '?' name::xs:token
   GlobalConstant ::= name::xs:anyURI

(I'm not suggesting that's the right design for Variable and
GlobalConstant, just that we may want to re-use the same property name
with two different value types.  If so, then [3] has to be equivalent to
[4] and not [2].)  If it turns out we don't want to re-use property
names like this, that would simplify things.

I haven't fully implemented the code for reading SBNF and outputting
asn, graphviz (UML-like diagrams), XML Schema, etc, but I've gotten far
enough along the way that I'm fairly confident it will work, and I
wanted to share this idea.

(There are some details about lists and Kleene operators, but I think
they can be managed.)

Thoughts?

      -- Sandro

Received on Thursday, 30 August 2007 19:12:15 UTC