One open design issue is whether DASL operators should be polymorphic or typed. The purpose of this email is not to argue one way or the other but to see whether we at least agree what the arguments each way are. Once we are clear on that, we can check for additional arguments, and try to assess those that point each way. In this email I tried to isolate the various arguments people have made and number them so we can discuss them. For each argument, I've given it a label (F or A for For or Against), a one line statement (in my words) and in some cases some argument that supports it. The supporting evidence is usually an (edited) quote from email. The kind of responses I'd like to this email are of the form 1) Here's an additional argument For or Against polymorphism 2) Your summary of argument N is misleading/wrong. Here's a better way\ 3) Here's additional evidence that supports or refutes point N FOR Polymorphism F1. polymorphism is simpler to define F2. polymorphism allows for simpler clients AGAINST Polymorphism A1. Polymorphic operators are expensive to implement leftIf the "greater than" operator were polymorphic, the query engine would case on the operator and end up in the case for "greater than", and then it would have to have a second switch statement on the operand types once it got there. The implementation cost and the run time cost of the extra switch statement is undesirable. There is no development or run time cost to making the "greater than" operator non polymorphic in the spec. There are only a few more lines of element declarations. A2. If errors arise, it will be difficult to provide a good error message. left...depending upon the RDBMS, I can tell you that the query may succeed or fail, depending upon which RDBMS is used. If the query fails, it would be difficult to pass an error back to the client that would make it clear what was going on. Thus, when errors occur on the server, there is always greatly increased difficulty of making it clear to (a) the human end user, (b) the support people he calls when things don't work, and (c) the programmers who get involved in the bug fixing, whether or not the bug is in their code or some other company's code as to what exactly went wrong. A3. Monomorphic operators make it possible to detect errors sooner, using XML syntax checking: A4. Monomorphic operators are much easier to describe in XML. leftFor the polymorphic operators, how are you going to express what combinations of types are legal, and which are illegal? You don't just want to have words in the spec. You want the element definitions to embody the correctness or incorrectness of the construction of the query. This is an industry standard. We need to be precise as to what is allow, and not leave holes. A5. Monomorphic operators will make interoperability with DMA easier (DMA uses monomorphic operators) A6. DMA designers rejected polymorphic operators. (This is a pointer to an argument, not an argument itself. Presumably the DMA designers were smart and thoughtful, and came to the conclusion that polymorphism was bad. But if they had any reasons other than the first four above, we have not heard them yet, so at present this is more like an argument from authority than a real argument.) A7. there is no extra burden in making the query language typed, because (some) UI query programs must deal with typing anyway (e.g. for syntax on input). leftA query UI program has to know whether the user is typing in a number, or a string, or a datetime. It cannot treat all these input fields exactly the same way. For example, the string representation of integers doesn't collate properly unless it is expanded with leading zeroes out to some maximum field length. For example, "1000" comes before "3". If you're typing in a date, the UI program has to check if you're typing in nonsense like more than 31 days in a month, more than 12 months in a year, etc.