Re: proposed: use abstract syntax notation (asn06)

> So, allow me the following questions:

Sure  :-)

> - How does it relate to the current syntax?

By "the current syntax" you mean the one given in

   http://www.w3.org/2005/rules/wg/wiki/B.1_Horn_Rules

etc, right?

I'm proposing that we use asn06 instead of EBNF so that we can write
down the "syntax" for RIF without needing to make decision about
keywords, punction, and term ordering.  I also think asn06, being closer
to an object-model/ontology language will help us be clearer about the
basic elements of RIF.  I think this will it much easier to implement
translators to/from RIF.

So the asn06 syntax for RIF that Harold and I sketched up [1] provides a
higher-level abstraction than the EBNF on the wiki.  The one on the wiki
could be a concrete syntax for this.

> - How do you disambiguate nested terms from flat terms in this syntax, etc.?

I don't think I understand that question.

> - What is the advantage of using this notion above the two proposed
> concrete and XML syntaxes proposed so far?

I think I've answered that in other e-mail.   If not, let me know.

> - Can you sketch some example rules or conditions using all three
>    syntaxes maybe to demo this?

I'm not proposing a syntax here, just a notation for writing down an
abstract syntax.

For example, the abstract syntax

  Customer
    name: string
    phone: string
    custid: number

could be concretized in this EBNF

[OPTION 1]

  Customer ::= "customer(" QUOTED_STRING ", " QUOTED_STRING ", " NUMBER ")"

  example:   customer("Sandro Hawke", "1-617-555-1212", 2323)

or this one:

[OPTION 2]

  Customer ::= "Name: " STRING NEWLINE
               "Phone: " STRING NEWLINE
               "CustID: " NUMBER NEWLINE

  example:    Name: Sandro Hawke
              Phone: 1-617-555-1212
              CustID: 2323

or an XML syntax like this:

[OPTION 3]

  <Customer>
    <name>Sandro Hawke</name>
    <phone>1-617-555-1212</phone
    <custid>2323</custid>
  <Customer>

or an XML syntax like this:

[OPTION 4]

  <datum>
    <str>Sandro Hawke</str>
    <str>1-617-555-1212</str>
    <num>2323</num>
  </datum>

.... etc ....

I think RIF has to make some decisions like OPTION 1/2/3/4, but I'd like
those decisions to be kept quite separate from what information is
actually being serialized in the language.

Does that make more sense?
  
   -- Sandro


[1] http://lists.w3.org/Archives/Public/public-rif-wg/2006Nov/0033

Received on Monday, 13 November 2006 20:10:08 UTC