From: Babich, Alan <ABabich@filenet.com>

Date: Mon, 18 May 1998 12:07:44 -0700

Message-ID: <72B1992276A9D111A20E00805FEAC96D0FD694@cm-expo1.filenet.com>

To: "'www-webdav-dasl@w3.org'" <www-webdav-dasl@w3.org>

Date: Mon, 18 May 1998 12:07:44 -0700

Message-ID: <72B1992276A9D111A20E00805FEAC96D0FD694@cm-expo1.filenet.com>

To: "'www-webdav-dasl@w3.org'" <www-webdav-dasl@w3.org>

> 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

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 20:22:38 UTC
*