W3C home > Mailing lists > Public > www-webdav-dasl@w3.org > July to September 1998

RE: datatyping is not needed

From: Babich, Alan <ABabich@filenet.com>
Date: Mon, 6 Jul 1998 22:24:12 -0700
Message-ID: <72B1992276A9D111A20E00805FEAC96DCC4141@cm-expo1.filenet.com>
To: "'Jim Davis'" <jdavis@parc.xerox.com>, www-webdav-dasl@w3.org
My comments interspersed.

Alan Babich

-----Original Message-----
From: Jim Davis [mailto:jdavis@parc.xerox.com]
Sent: July 06, 1998 8:35 PM
To: www-webdav-dasl@w3.org
Subject: datatyping is not needed


I would like to propose that DASL does not need any datatyping.  Near as
I
can tell there are two possible functions for datatyping

1) Enables better UI.  If the query grammar schema indicated the
datatype
of each property, then a smart UI could use this to constrain the user's
data entry, e.g. ensure that only valid dates were entered into a date
field for comparison with a date, etc.

2) Query processing. Some underlying search systems are strongly typed.
For example, properties in DMA are strongly typed.  Even to get the
value
of property, you must know the datatype.

Now I'll show why neither one is a good reason for datatyping in DASL

1 - I don't deny that datatyping is useful to a UI, but I claim that it
isn't sufficient for a really good UI.  A good UI will want a great deal
of
additional information as well, and this information can't be provided
via
DASL datatyping.  For example:

1) Range constraints on numbers (enter an integer < 100)
2) Value constaints (e.g. A Canadian postal code has alternating letters
and digits.  You *could* express this with e.g. COBOL Picture datatype,
but
that's not an XML Data dataype.
3) Value constaints between properties.  Suppose you're entering a date
range.  The first date should be before the second one.  Such
constraints
are likely to be implemented in some constraint or scripting language
(EcmaScript, JavaScript, ActiveTcl).
4) Property documentation (e.g. typical value, default value,
human-readable documentation)

DASL can't solve all of this, so it needn't bother solving any.  
[ALAN BABICH: As regards the premise, I don't believe DASL
has to solve ALL of your examples. I believe it would be extremely
useful if DASL solved SOME of them, e.g., default value, range
constraints, and datatype. As regards to the conclusion, even
if you buy the premise, the conclusion doesn't follow: (1) So I 
couldn't afford a Ferrari Testarosa, so a Corvette 
is no good at all, and so I walk? Nope. I own a Corvette ZR1, 
and "Cogito, ergo zoom". Driving at speeds up to 180 mph 
sure beats walking at speeds up to 3 mph. 
(2) What, the first release of my company's system
in 1987 didn't do everything we could think of at that time,
so we should have given up in 1987 and gone out of business?
Well, the customers thought the system was quite
useful, and so they paid us a lot of money for it.
Through all the releases including the latest, our system
has never done everything that we could think of or that
the customers requested, and yet the customers still find 
the system useful and pay us lots of money for it.]

These
smart UIs are going to get most of this information from some other
source,
so they may as well get the datatype there, too.
[ALAN BABICH: If they get their information from some other
source, DASL is inadequate. So why won't they ignore DASL 
completely and simply use the other source directly? I can't
think of any other source that's always available except the 
underlying system itself. The underlying system can, by definition, 
do everything the underlying system can do. DASL, by definition,
probably can't. In other words, I don't believe this line
of reasoning is valid. We can't let DASL be inadequate.
It's good that we seem to agree that smart UI's are a good thing.]

2- In the case of for query processing, the underlying server already
knows
the datatypes, it does not need to be told.  For example, DMA provides
the
PropertyDescription property that tells the datatype.  So if you want to
compare e.g.
 <lt>
   <prop><age/></prop>
   <literal>7</literal>
 </lt>

the server has all the info it needs to convert the string "7" to an
integer.  It knows that the target datatype is "integer" and it has the
string data.
[ALAN BABICH: I believe your assertion is correct. Every document
management system, digital library, or DBMS I know of can give you 
its metadata if you ask. However, for the sake of interoperability,
DASL must state that the datatype of the literal must be compatible
with the datatype of the property and give all the details.]

We add no value by expressing the literal with an explicit datatype.
[ALAN BABICH: My proposal is not to decorate the literal or the 
properties in the QUERY CONDITION with a datatype, but to ADVERTISE 
the datatype as an attribute of the properties
supported by the scope list when the client requests the query
capabilities. Having done that, the client can get the datatypes
and other metadata once, remember it, and check queries, and 
present the metadata to the user on demand if it wishes to do so.
Or, it can try to ignore the datatypes. The client doesn't even 
have to get the properties or query operators that are supported.
It can let you guess the properties and operators, and let 
the server give you "bad query" errors on all your wrong guesses 
and spelling errors, and let you guess which parts of your query 
were incorrect. I believe our job is to make quality implementations 
and efficient implementations possible, but not 
to require that (because we can't really require that).
Advertising datatype on the literals and properties in the
QUERY CONDITION is redundant if you have it in the metadata,
so I have proposed not to bother. We seem to be basically in 
agreement on that point.]

Finally, such datatyping would have to be optional anyway.  There are
servers that don't care about datatype.
[ALAN BABICH: I don't see the "must be optional" argument.
What are a couple of examples of servers that "don't care" about 
datatypes?]

We don't need datatype, so let's toss it.
[ALAN BABICH: And fail to meet our charter? And fail to make
quality implementations possible? Not a good idea, since 
all that has to be done is to decorate the properties with their
datatype when the query capabilities are advertised. 
Over time, I'm sure that more metadata will inevitably be
added to decorate the DASL properties, e.g., default value,
range constraints, etc. I'm also sure that additional datatypes 
will be defined in DASL. Resource classes will also be introduced.
Software evolves or dies. There is already an effort underway 
to add datatypes to XML, viz. XML Data. Datatypes are too important 
to simply ignore them. There is nothing to be gained by failing
to decorate the properties advertised to be supported with their 
datatype, and there is something important to be lost.]
Received on Tuesday, 7 July 1998 01:26:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 03:38:04 GMT