ebxml-regrep message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Comment on Predicates Proposal

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

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC