design issue: query type checking via DTD

This message attempts to summarize a design issue that has been
discussed at some length in this forum, but not yet resolved.  This
message summarizes the design issue and the arguments that have thus
far been advanced for and against it.

Appropriate responses are:
 * The design issue is not correctly stated, but should instead be ...
 * An Additional argument (pro or con) is ...
 * Argument X is misstated, it should be ...

Issue: should the DASL DTD for query be defined such that one can do
type-checking on a query simply by validating the query against the
DTD?

  Context: This issue is, in some sense, a followon to an earlier
  issue summarized in "Design issue: polymorphism".  That issue was
  whether DASL operators should be polymorphic.  There, the chief
  argument against such polymorphism was that it prevented type
  checking.  We now have a proposed DTD (see Alan Babich's email of
  Sun, 10 May 1998 18:45:18 PDT) that is polymorphic while still
  allowing type checking, so that particular design issue is moot.
  While some have objected to the complexity of that DTD, its claimed
  advantage is that it supports type checking.  This raises the
  logically prior issue of whether a DTD *should* support type
  checking.  If we agree that it should, we can then debate specific
  proposed DTDs that do that.  If we agree that it needn't (or
  shouldn't) then we should consider different DTDs.

Arguments are labelled P for Pro and C for Con.

P1. It makes error checking easy, because it suffices to use a
validating XML parsers, which is easily obtained.

P2. It enables clients to do client side checking, which is good
because you get a better UI by detecting errors as early as possible.
Advanced UIs are likely to require strong typing anyway, when
prompting for values and accepting input (e.g. to accept only
correctly formatted dates or integers.)

  [This is really an argument for strongly typed queries in general,
   not for the specific approach of using a DTD for such strong
   typing.]

P3. It relies only on core XML features, as opposed to extensions or
conventions such as XML-Data that are still being designed.

C1. It makes the query syntax more complicated.  Compare

<where>
  <boolean_op>
    <eq>
      <string_expr>
        <string_prop>dav:getcontenttype</string_prop>
      <string_expr>
      <string_expr>
        <string_const>image/gif</string_const>
      </string_expr>
    </eq>
  </boolean_op>
</where>

with 

<where>
    <eq>
      <prop>dav:getcontenttype</prop>
      <string_const>image/gif</string_const>
    </eq>
</where>


C2. Servers can't rely on clients to do the syntax checking anyway, as
some clients won't bother, and others may be either buggy or malicious

C3. A DTD may not be sufficient for type-checking, because WebDAV properties
are not typed.

C4. A DTD is not sufficient for all error checking, since for example
a property might not be defined on a given resource.

Received on Friday, 29 May 1998 18:54:38 UTC