Comment on Predicates Proposal

[Len Gallagher <LGallagher@nist.gov>]

Version 0.2 of Scott Hinkleman's Predicates proposal defines a
CompoundClause as follows:

 <!ELEMENT CompoundClause  ( Clause, Clause+ )>

Take the following expression:  A and B or C.  This expression could get
interpreted as: 
 
   A and (B or C)   or as   (A and B) or C

depending on how the CompoundClause gets encoded by the client application. 

With a little more effort we could avoid this potential confusion by
re-defining Clause and CompoundClause as follows:

<!ELEMENT Clause  ( BooleanTerm | CompoundORclause )>

<!ELEMENT BooleanTerm  ( SimpleClause | CompoundANDclause )>

<!ELEMENT CompoundORclause ( Clause, BooleanTerm )

<!ELEMENT CompoundANDclause ( BooleanTerm, SimpleClause )>

NOTE: The above are derived from the BNF for a <search condition> in the
SQL standard, ISO 9075, with some name substitutions.

Under this definition, the expression "A and B or C" can be encoded in only
one way, i.e. first as a CompoundORclause, whose Clause is a BooleanTerm
that is a CompoundANDclause and whose BooleanTerm is a SimpleClause. 

With this encoding, the expression "A and B or C" can only be interpreted
as (A and B) or C. I believe this is what is required by the usual rules of
logic.

Is the added complexity worth the added precision?

-- Len







 
**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************