RE: sbnf (striped BNF)

"Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca> writes:
...
> [7]   Implies ::=3D 'Implies'
>                     '('
>                         'then' '->' ATOMIC
>                         'if'   '->' CONDITION
>                     ')'
>
> where slot names 'then' and 'if' are local to the 'Implies'.
> In interpretations, the order between these '->' slots does
> not matter. (RIF could then also encode the abstract syntax
> of its own rules as slotted Uniterms:
> http://www.w3.org/2005/rules/wg/wiki/Core/Slotted_Conditions)
> 
> Rather than regarding the '::' or '->' pairs as "in-line
> productions", they are now part of the terms defined through
> the Abstract EBNF Syntax.

I had some trouble understand your message, so I may have missed or
misunderstood it.  But I think you're suggesting having two real
languages.  Specifically:

    1.  The "concrete" syntax, defined using normal EBNF, where a rule
        might look like this:

> discount(?Customer) :- loyal(?Customer)

and:

    2.  The "abstract" (which is still a real, concrete syntax), defined
        using a modified grammar language, AEBNF, where that same rule
        instance might look like this:

> Implies
>   (
>     then -> Uniterm
>               (
>                 op  -> Const(discount)
>                 arg -> Var(Customer)
>               )
>     if   -> Uniterm
>               (
>                 op  -> Const(loyal)
>                 arg -> Var(Customer)
>               )
>   )

Is that right?

> Given an Abstract EBNF (instead of asn06), with rules
> like [7], and a Concrete EBNF (as before), with rules
> like [1], there can be mappings in both directions.
> For the purpose of our spec, the primary direction of
> mapping is again from abstract to concrete.
> 
> Both grammars themselves and their instances can be mapped.
> The abstract-to-concrete mapping algorithms would basically
> 'positionalize' the canonically (e.g., lexicographically)
> sorted slots, and move certain abstract constructors, e.g.
> 'Implies', into the position of infix operators, e.g. ':-'.

I understand mapping the instances automatically, but how do you map the
grammars automatically?  There's no way for the mapper to know you want
to use ":-" for implies, etc.   If you want to only maintain one
grammar, I believe it has to be a fully-striped "concrete" one.

So:

  1.  I don't see what advantage aebnf has over asn, if we're going to
      maintain both an abstract grammar and a concrete grammar.  I guess
      it's closer to EBNF which makes it more intuitive for some people,
      but I'm not persuaded that it is.  (Programmers are used to
      reading both data definitions and EBNF.  The abstract syntax is
      closer to a data definition, so asn looks more like a data
      defintion.)

  2.  The point of SBNF is largely to allow us (and other dialect
      developers) to maintain only one grammar from which the others can
      be automatically derived.  This allows a kind of bottom-up design.
      I know top-down design is more appealing to many -- that is, we
      should settle on the abstract syntax first, and then work on the
      presentation syntax -- but we've had some troubles with that, so I
      figured I would suggest this SBNF approach.

  -- Sandro


> -- Harold
> 
> 
> -----Original Message-----
> From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
> On Behalf Of Sandro Hawke
> Sent: Thursday, August 30, 2007 4:10 PM
> To: public-rif-wg@w3.org
> Subject: 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  ::=3D 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 ::=3D then ':-' if
>       then ::=3D ATOMIC
>       if ::=3D CONDITION
> 
> That gets pretty tedious pretty quickly, so I suggest we use an "in-line
> production" syntax, like this:
> 
> [3]   Implies ::=3D 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 ::=3D Implies__then ':-' Implies__if
>       Implies__then ::=3D ATOMIC
>       Implies__if ::=3D CONDITION
> 
> This allows us to have things like, where the property "name" is shared:
> 
>    Variable ::=3D '?' name::xs:token
>    GlobalConstant ::=3D 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 Monday, 3 September 2007 12:07:34 UTC