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

["Gerhard Dieringer" <DieringG eba-haus de>]

Hi Vivien,

as you also didn't like the chain element:

> > ----> I'll have to think a bit more about this, since I first thought it would
> > be better to chain entire queries.

I dropped it and replaced it it by a new trailer element, defined as follows:

<!ELEMENT query (target?, sources?, joins*, values?, qual?, trailer?>

<!ELEMENT trailer (query|sort)>
<!ATTLIST trailler
                  type (union|unionall|intersect|minus) #IMPLIED>

This has the following advantages:
- it chains entire queries, as you liked ;-)
- it reflects the fact, that only the last subquery of a union-chain may have a sort clause
- it was very easy to integrage into your SQL renderer and works fine :-))

> 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.

You are right. I'm sorry, but I'm just starting to use XML and I think it will still take some time
to realize the chances that it offers.

So what do you think of the following extension of the fielddef element:

<!ELEMENT fielddef (#PCDATA)>
<!ATTLIST fielddef
.....
     type (int|float|varchar|fixedchar|datatime|nonstandard) #REQUIRED
..... 

If we want to have a standard data type, we can express it with the attributes,
if we need a nonstandard or user defined data type, we can express it with
an arbitrary child structure.

example:
three-dimensional integer array in PostgreSQL (integer [3][4][5]):

<fielddef name="ar3col" type="nonstandard">
  <array type="int" size="4" >
     <dim size="3">
     <dim size="4">
     <dim size="5">
  <array>
</fielddef>


> 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.

I don't understand your objection. The sequence element was intended to create
a new sequence with a minimal set of featues. I can't imagine, that a DBMS offers the
possibility to ask: what kind of sequences do you support, because it only has one builtin
type and the provider should know its features.
I think I only can ask the parameters of one existing sequence:
What is your current value?, your start value?, your increment value?,...

But that doesn't care, because I just want to create a new one.

Please tell me, if I'm very wrong.


Gerhard