Formal proposal for DASL "where" condition

> I attempted to answer my own question,
> "If you had polymorphic operators,
> how would the ELEMENT declaration call out only
> the cases that are legal and exclude the rest?".
> I have thought about it, and I am making the following
> formal proposal for the "where" condition:
> 
> 
> <!ELEMENT where ( boolean_op ) >
> 
> <!-- These are all the operators that return a Boolean value -->
> <!ELEMENT boolean_op ( and | or | not | 
>                        gt | gte | eq | ne | ls | lse ) >
> 
> <!ELEMENT and ( boolean_expr , boolean_expr+ ) >
> <!ELEMENT or ( boolean_expr , boolean_expr+ ) >
> <!ELEMENT not ( boolean_expr ) >
> <!ELEMENT gt ( ( integer_expr , integer_expr ) |
>                          ( real_expr , real_expr ) |
>                          ( integer_expr , real_expr ) |
>                          ( real_expr , integer_expr ) |
>                          ( string_expr , string_expr ) |
>                          ( datetime_expr , datetime_expr ) ) >
> <!ELEMENT gte ( integer_expr , integer_expr ) |
>                          ( real_expr , real_expr ) |
>                          ( integer_expr , real_expr ) |
>                          ( real_expr , integer_expr ) |
>                          ( string_expr , string_expr ) |
>                          ( datetime_expr , datetime_expr ) ) >
> <!ELEMENT eq ( integer_expr , integer_expr ) |
>                          ( real_expr , real_expr ) |
>                          ( integer_expr , real_expr ) |
>                          ( real_expr , integer_expr ) |
>                          ( string_expr , string_expr ) |
>                          ( datetime_expr , datetime_expr ) ) >
> <!ELEMENT ls ( integer_expr , integer_expr ) |
>                          ( real_expr , real_expr ) |
>                          ( integer_expr , real_expr ) |
>                          ( real_expr , integer_expr ) |
>                          ( string_expr , string_expr ) |
>                          ( datetime_expr , datetime_expr ) ) >
> <!ELEMENT lse ( integer_expr , integer_expr ) |
>                          ( real_expr , real_expr ) |
>                          ( integer_expr , real_expr ) |
>                          ( real_expr , integer_expr ) |
>                          ( string_expr , string_expr ) |
>                          ( datetime_expr , datetime_expr ) ) >
> 
> <!-- No operators are currently defined that return integer,
>      real number, string, or datetime values.
> -->
> 
> <!-- The following elements define all Boolean valued expressions -->
> <!ELEMENT boolean_expr ( boolean_op | boolean_prop | boolean_const ) >
> <!ELEMENT boolean_prop ( #PCDATA ) >
> <!ELEMENT boolean_const ( "t" | "f" | "unknown" ) >
> 
> <!-- The following elements define all integer valued expressions -->
> <!ELEMENT integer_expr ( integer_prop | integer_const ) >
> <!ELEMENT integer_prop ( #PDCATA )
> <!ELEMENT integer_const ( #PCDATA )
> 
> <!-- The following elements define all real number valued expressions
> -->
> <!ELEMENT real_expr ( real_prop | real_const ) >
> <!ELEMENT real_prop ( #PCDATA) >
> <!ELEMENT real_const ( #PCDATA ) >
> 
> <!-- The following elements define all string valued expressions -->
> <!ELEMENT string_expr ( string_prop | string_const ) >
> <!ELEMENT string_prop ( #PCDATA ) >
> <!ELEMENT string_const ( #PCDATA ) >
> 
> <!-- The following elements define all datetime valued expressions -->
> (!ELEMENT datetime_expr ( datetime_prop | datetime_const ) >
> <!ELEMENT datetime_prop ( #PCDATA ) >
> <!ELEMENT datetime_const ( #PCDATA ) >
> 
> = = = = = = = = = = = = = = = = = = = = = = = = = = = 
> 
> This gives DASL polymorhpic comparison operators, 
> e.g., "gt", "gte", "eq", "ne", "ls", "lse".
> Yet, DASL would have the invariant condition that I
> belive is really important, which is, 
> "correctly constructed query if and only if validity". 
> This makes it possible for query construction errors
> to be caught on the client side as a side effect of
> checking for validity, for those folks who
> want to make the check. It has a bit of a performance
> impact on the server, but not much, and it doesn't
> make the server code that much harder.
> 
> I left out the "contains" operator, because, as
> it stands, it is nowhere near fully baked.
> The issues of stemming, phrases, nearness,
> wildcards, etc. remain to be dealt with.
> I'm sure we'll deal with these and end up with
> one or more content based retrieval operators, 
> but those issues deserve to be a separate discussion
> topic. There is already some e-mail about content
> based retrieval issues.
> 
> 
> 
> Alan Babich
>

Received on Monday, 18 May 1998 15:10:24 UTC