RE: ANY in the DASL spec

I think I must have missed out on some conversations around simplifying the
grammar.  I still believe, though, that precision is essential to a
grammar, and simplicity can't be allowed to lead to vagueness.  We can
simplify the grammar by making it less powerful, but not by making it less
precise.  The more we can convey in the formal grammar, the easier we make
life for implementers.  Enough preaching.

It's true that since DAV:prop is defined as ANY, we don't really gain
anything formally by saying

<!ELEMENT eq ((prop | literal), (prop | literal))>

but I think we do give a much clearer view of our intent than just

<!ELEMENT eq (ANY, ANY)>

As for allowing math operations, since this is a grammar for simplesearch,
we could simply make a decision that it's not part of that grammar to allow
mathematical operations in the arguments of a comparison.  If we want to
allow math operations, I think we should bite the bullet and explicitly
define the grammar for them, and make it clear which ones are allowed.

I'm looking at a complete, precise grammar for SQL that takes less than 3
pages of bnf.  We only need a small subset of that.

Here's a flavor of what the grammar might be like getting rid of ANY and
allowing math (probably with lots of mistakes because I'm not very good at
this):

<!ELEMENT where (and | or | not | comparison)>

<!ELEMENT and (and | or | not | comparison | prop | literal), (and | or |
not | comparison | prop | literal)>
.
.
.

<!ELEMENT comparison (eq | lt | le | gt | ge | contains | extension)>

<!ELEMENT eq (term, term)> 
.
.
.

<!ELEMENT term (prop | literal | mult | div | add | sub | extension)>

<!ELEMENT contains (prop?, literal)>

<!ELEMENT mult (term, term)>

<!ELEMENT div (term, term)> 
.
.
.

Example:

<where>
  <and>
    <or>
      <prop> <is-archived/> </prop>
      <comparison>
        <eq>
          <prop> <author/> </prop>
          <literal> "Smith" </literal>
        </eq>
      </comparison>
    </or>
    <comparison>
      <gt>
        <prop> <current-size/> </prop>
        <term>
          <mult>
            <prop> <create-size/> </prop>
            <literal> 10 </literal>
          </mult>
        </term>
      </gt>
    </comparison>
  </and>
</where>

(I'll stop nagging at this point and leave the decision up to you.)

At 11:29 AM 4/21/98 PDT, you wrote:
>
>I claim the the reasons you say ANY is worse actually cause it to be better
>...
>
>If only Prop is allowed then a > operation could only look like this
>(ignoring literals for the moment)
>
>	propname1 > propname2
>
>But never
>	
>	propname1 > ( propname2 * 10 )
>
>And similarly, extension for other kinds of server-specific functions is not
>allowed ...
>
>	propname1 > foo:baroperator ( propname2 , 10 )
>
>Whenever ANY appears (as it does for DAV:prop) we are going to have to
>supplement the DTD with sections in the draft that elaborate on the
>restrictions and interpretations -- this is true for both ANY and DAV:prop.
>Because they both equal ANY then I claim there's no point adding an extra
>DAV:prop layer to contain the property name.
>
>-Saveen
>
>-----Original Message-----
>From: Judith Slein [mailto:slein@wrc.xerox.com]
>Sent: Tuesday, April 21, 1998 7:32 AM
>To: Saveen Reddy (Exchange)
>Cc: www-webdav-dasl@w3.org
>Subject: RE: ANY in the DASL spec
>
>
>I think the grammar has to be as specific as possible.  Whenever we say
>ANY, an implementer really can put any construction of defined elements
>there, and it will be valid.  We should not say this is valid unless we
>really mean it.  I think readability is not a criterion for a good grammar
>definition (unless we are deciding between two logically equivalent
>expressions, one of which is more readable than the other).
>
>You are right about the where element definition -- since extensibility is
>desired, there is probably nothing for it but to define where to be ANY,
>and explain in the text what sort of elements are really acceptable.  You
>have done a nice job of this.
>
>It's true that in the operator definitions, prop would not be ideal because
>we still have to explain in text that only single-valued instances of prop
>are allowed, but ANY is even worse, since it allows multi-valued prop
>elements and all sorts of other stuff like from elements, sortby elements,
>etc.
>
>--Judy
>
>At 02:24 PM 4/20/98 PDT, Saveen Reddy (Exchange) wrote:
>>Going to DAV:operator instead of any I think induces two problems:
>>
>>1 - makes the grammar more unreadable. I know this is in some ways not a
>big
>>deal -- no user will see these queries, but having a lot of XML:elements
>>makes it confusing. People, by far, wanted the "low-fat" grammar in "01"
>>than the original "00" grammar.
>>
>>2 - And this is the more serious concern ... I think this limits the
>>extensibility. The point of saying ANY in this case was to allow search
>>arbiters to easily extend the search grammar. If they needed to have a new
>>operator they can implement one and expose it as a namespaced XML element
>>without fear of interfering with other operators. 
>>
>>As for moving DAV:prop and DAV:literal for all the search operators I think
>>this doesn't add any new capability -- if the element isn't DAV:literal
>then
>>there is nothing else it can identify except a property. Adding a prop
>>element in this case is also perhaps harmful ... DAV:prop is defined to
>>potentially contain multiple properties, not a single property.
>>
>>-Saveen
>>
>
>Name:			Judith A. Slein
>E-Mail:		slein@wrc.xerox.com
>Internal Phone:  	8*222-5169
>Fax:			(716) 422-2938
>MailStop:		105-50C
>Web Site:    http://www.nde.wrc.xerox.com/users/Slein/slein.htm
>
>
Name:			Judith A. Slein
E-Mail:		slein@wrc.xerox.com
Internal Phone:  	8*222-5169
Fax:			(716) 422-2938
MailStop:		105-50C
Web Site:    http://www.nde.wrc.xerox.com/users/Slein/slein.htm

Received on Tuesday, 21 April 1998 17:37:59 UTC