Re: Antw: Re: revised gda-xml-query.dtd

[Vivien Malerba <malerba linuxave net>]

On mar, 18 jui 2000, you wrote:

> > ...
> > <!ELEMENT chain (sources, joins*, values, qual?)>
> > <!ATTLIST chain 
> >           type (union|unionall|intersect|minus) #REQUIRED>
> > 
> > ----> I'll have to think a bit more about this, since I first thought it would
> > be better to chain entire queries.
> > ... 
> 
> You are right. When I tried to implement it in your gda-xml-query.c (you got me revised version?), I found that it's not a good solution for union, ...
> But until now I didn't find a better one.

I got your version but still haven't had the time to have a look at it (I'm
changing job location next week and I have a LOT of things to do before leaving
here, so not a lot of time left). I'll think about that.

> > ...
> > <!ELEMENT fielddef EMPTY>
> > <!ATTLIST fielddef
> >           id   ID      #IMPLIED
> >           name NMTOKEN #REQUIRED
> >           type (int|float|varchar|fixedchar|datetime) #REQUIRED
> >           size CDATA   #IMPLIED
> >           notnull (yes|nos) "no">
> >
> > --------> The type is too much limited like this, we should put a NMTOKEN
> > instead. But I don't know how to care about data types which require one or
> > more arguments (such as varchar(30) or varchar(50)). Any idea?
> > ..
> 
> the size was intended for that: varchar(30): type="varchar" size="30"
> We could add another attribute 'scale' and use the following mapping:
> 
> type="float" size="10" scale="5" 
> Oracle:            NUMBER(10,5)
> PostgreSQL:   FLOAT8, or FLOAT4 if size < 6, ignoring scale
> other DBMS: I only known other DBMS by name and can't say anything about them.
> 

Ok, but I'm not really sure one cannot create data types which will require
more than one parameter (user defined data types), and in that case we have to
find another solution. Anyway, for now it looks OK for me as you propose it!

> My idea of limiting the type was to allow only types, that all (usable) DBMSs support. 
> 

The schema behind XML queries is that one: the client gets many information
from the DBMS provider he is connected to and then he creates queries from what
he has learnt. The XML is the 'universal language' to which the client speaks
to the provider to ask it to do specific operations. XMl queries are not made
so that a query will work for another provider (not because of the structure
but because of the actual contents of the query).

So I don't agree with you on this. From a client point of view, he can know all
the data types available, and for the tables' fields their real data type. If
we want to use XML queries, we need to allow the client to specify the data
type he wants.

> > ...
> > <!ELEMENT sequence EMPTY>
> > <ATTLIST  sequence
> >           name  NMTOKEN #REQUIRED
> >           start CDATA   #IMPLIED
> >           inc   CDATA   #IMPLIED>
> > 
> > ---------> I wonder if it is enough to define sequences for ALL the DBMS (I
> > know that postgres allow the user to set more attributes, what about the
> > others). We have to think more about it :)
> 
> It was only a first suggestion, but with the same intention as above. 
> 

The problem here is not the same as for data types since for now the client
cannot know the internals of a sequence. All he can learn is if the DBMS
supports sequences and if so what sequences there are (and not some other
details of each sequence).

To be exact, the GDA_Connection_GDCN_SCHEMA_SEQUENCES schema returns the
sequence name, its owner, some comments, and an SQL definition.

IMO that element would be used to store the structure of a DB, and build it
back another time. From a client point of view these are the 2 operations
he wants to do, and not know exactely what the attributes of the sequence are
(if you need to know more about sequences we have to modify what is returned
from the GDA_Connection_GDCN_SCHEMA_SEQUENCES schema). So what the client could
do is either: 
1) ask the provider to give him an opaque definition of the sequence (an SQL
statement or whatever); or
2) ask the provider to give him the complete XML element for the structure.
The 1) should be easier to implement because it already exists (as said above).

That way the purpose of the XML queries is respected, and we can store objects
(not limited to sequences) without knowing very much of them.

> 
> Gerhard

That's quite a long mail, tell me if you disagree with my point of view on the
XML query usage.

Regards,

Vivien