RE: datatyping is not needed

* MY POSITION 

> - Alan Babich: need to advertise types in QSD
Yes, that's the brief version of my position.

To expand on it a bit, I think we only need to
be explicit about the most fundamental five
datatypes in the QSD, and should lump all others into
"other" for 1.0, in order to limit the problem
to whats important and leave things open for future 
extensions.


* OBSCURE DEAD PROPERTIES

As far a PROPPATCH setting the value of a property:
PROPPATCH does not normally have to specify the 
type of the value, because in practice the server 
knows what the type of the value is (for properties). 
What most (maybe even all) existing systems do that are
serious about properties (e.g., document management
systems, RDBMS's, etc.) is to insist that all the
values of a property are drawn from a datatype domain
defined by the schema. As a consequence, all values
are homogeneous for a property. In other words, common
practice does not allow the possibility of obscure 
dead properties. 

If DASL 1.0 ignored the concept of properties for which the 
server accepts values from multiple domains (e.g., multiple 
character sets or multiple collation sequences) that are 
determined by the client at run time, I think we would
be OK. In other words, if DASL 1.0 ignored obscure dead 
properties, I think we would be OK.


* CHARACTER SETS AND COLLATING SEQUENCES

As input to our decision process, let me try to give
a simplified summary of the relevant part of what 
I think SQL does, since SQL is one important use case, 
and a lot of thought has been put into it.

There are three levels of SQL conformity: entry level,
intermediate, and full SQL. 

In intermediate and full SQL, one can name the character
repertoire of a string literal.

In full SQL and only full SQL one can use a collate clause 
to designate the use of a named collating sequence in certain 
parts of a query.

There is a default character repertoire and default 
collating sequence for every property and string literal. 
(The case sensitivity aspect is generally considered as part 
of the definition of the collating sequence.)
When comparing a property against a string literal, the 
default collating sequence of the property and the literal 
is used unless overridden. If the default collating sequence 
of the property and the literal are not the same, an explicit
specification of the collating sequence is required
(but is only possible in full SQL).

If two explicit collate clauses conflict, that is a syntax
error.

If one of the two operands has an explicit collate
clause and the other is coercible, the explicit collating
sequence is used.

<collate clause> is "COLLATE mycatalog.myschema.mycollation"
(mycatalog and myschema are optional).
It is important to note that an explicit collate clause
does not decorate the operator, it decorates the operand(s).

I have two hopes for possible simplification. (1) I hope
that UCS is sufficient, i.e., that for 1.0 we
don't have to make specification of different character
sets possible. This would not just affect DASL, it
would affect PROPFIND and PROPPATCH, i.e., WebDAV.
(2) I hope we can consider explicitly overriding
collating sequences (other than just a global overriding
default derived from locale) to be an advanced feature, 
i.e., post 1.0.


Alan Babich

> -----Original Message-----
> From: Saveen Reddy [mailto:saveenr@microsoft.com]
> Sent: July 17, 1998 12:52 PM
> To: Saveen Reddy (Exchange); www-webdav-dasl@w3.org; Jim Davis
> Subject: Re: datatyping is not needed
> 
> 
> Comments below ...
> 
> -----Original Message-----
> From: Jim Davis <jdavis@parc.xerox.com>
> To: Saveen Reddy (Exchange) <saveenr@exchange.microsoft.com>;
> www-webdav-dasl@w3.org <www-webdav-dasl@w3.org>
> Date: Wednesday, July 15, 1998 12:14 AM
> Subject: RE: datatyping is not needed
> 
> 
> >At 11:50 PM 7/14/98 PDT, Saveen Reddy (Exchange) wrote:
> >
> >> then a plausible
> >>scenario exists where detatyping is required for obscure 
> dead properties.
> >>Some implementations will allow searching (even if the 
> query is not as
> >>efficient for some "famous" property).
> >
> >While I confess that I can recognize this scenario as 
> *possible*, still I
> >don't find it very probable.  Without indexing, it's hard 
> for me to believe
> >in exhaustive search.   I can admit that in some cases it 
> might be done,
> >still I also don't find it nearly as strong as the other 
> scenarios.  I
> >wouldn't call DASL a failure if it didn't have it.
> >
> 
> OK, I disagree about how likely this is. I believe the use of 
> obscure dead
> properties + exhaustive search (as painful as that might be for server
> performance) is probably the lowest bar for implementing a 
> dav server and
> because of that bound to be likely.
> 
> >And I am troubled by the notion of post-facto imposing 'typing' on
> >properties people stored, and by the added work we'll have 
> to do to define
> >this precisely.  Just to take one example, the (obscure 
> dead) property
> >'foo' on resources R1 and R2 has values "BABE" and "FAD" 
> respectively.  Now
> >if we sort by 'foo' and the client says nothing about the 
> datatype, then R1
> >comes before R2 because the string "BABE" is alphabetically 
> before "FAD".
> >But if the client asserts that these are really numbers expressed in
> >hexadecimal, then it's the other way around.  Will we 
> *require* that all
> >compliant DASL servers support all the type coercions?  And 
> remember, once
> >we define it, we can't easily be rid of it.
> 
> 
> If I understand you correctly you are saying: we shouldn't 
> define any type
> casting in the query. I suspect we may be closer to agreement 
> than it may
> first appear.
> 
> Here's my attempt to summarize the views ... (someone tell me 
> if I have this
> incorrect)
> - Jim Davis: don't need type casting in the query
> - Alan Babich: need to advertise types in QSD
> - Saveen Reddy: Type casting I'm not sure about, but clients 
> do need a way
> to set the type of a property with PROPPATCH, because 
> naturally this will
> affect how a query (even without type casting gets done). 
> With either type
> casting or setting the type with PROPPATCH we can't avoid the issue of
> typing.
> 
> >I think we have some very hard pieces of work ahead of us 
> without getting
> >into this.  Consider all the open issues not yet resolved, 
> surely we are
> >better off letting this one go?  I mean, we still have to 
> figure out what
> >content based retrieval to support, and whether and how to 
> support any
> >structure query.  These are surely way more central and 
> important than
> >sorting on the obscure dead?
> 
> 
> Sorting of the obscure dead may not be so important, but 
> *query criteria*
> using the obscure dead is, IMO.
> 
> Even if we simply drop type casting from the query, we still 
> have to address
> how the server will deal with types in the query (for example 
> under what
> criteria is a string equivalent to another string). Without type
> casting/coercion thrown into the mix this just doesn't seem 
> that complex.
> 
> -Saveen
> 
>

Received on Monday, 20 July 1998 20:11:42 UTC