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

Received on Tuesday, 21 April 1998 10:26:23 UTC