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

[Vivien Malerba <malerba linuxave net>]

On mer, 19 jui 2000, you wrote:
> 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 :-))
> 

Ok, nice idea!

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

It's not about the XML language (which you seem to know more than me), but
about how to use it for queries. When I first proposed to use XML, it was
because as a client can't know which DBMS it is connected to, we needed a
universal 'language' to make queries, that's all! 

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

This means that the <array> element cannot be defined in the DTD (as for
other nonstandard data types), which is not really nice!

There is a difference between arrays and other data types like
varchar: arrays need one arg to tell them the data type stored and others for
the dimensions, and are written type[?][?][?]... Other data types like varchar
need one arg for its size and is written varchar(?). We could imagine other
data types which would require more args and would be written dummy(?,?).

I propose the creation of several new elements:
<!ELEMENT datatypearg (datatypedef)?>
<!ATTLIST datatypearg
          order (1|2|3|4|5|6|7|8|9|10) #REQUIRED
          value NMTOKEN #IMPLIED>

<!ELEMENT datatypedef (datatypearg)*>
<!ATTLIST datatypedef
           name NMTOKEN #IMPLIED>

<!ELEMENT fielddef (datatypedef)?>
<!ATTLIST fielddef
           id   ID      #IMPLIED
           name NMTOKEN #REQUIRED
           type NMTOKEN #REQUIRED
           size CDATA   #IMPLIED
           notnull (yes|no) "no">


To be used as:
* always give the data type name as the 'type' attribute
* if there needs to be more details about the data type, then use a
'datatypedef' element to give those details.
* if the type name is "array", then the first datatypearg element given MUST be
the data type for the array, and the next ones the dimensions of the array.

Your 3 dim array example would give:
<fielddef name="ar3col" type="array">
  <datatypedef>
    <datatypearg order="1" value="int4"/>
    <datatypearg order="2" value="3"/>
    <datatypearg order="3" value="4"/>
    <datatypearg order="4" value="5"/>
  </datatypedef>
</fielddef>

a varchar(25) would be:
<fielddef name="vchar25" type="varchar">
  <datatypedef>
    <datatypearg order="1" value="25"/>
  </datatypedef>
</fielddef>

an array like varchar(25)[10] would be:
<fielddef name="arvchar25" type="array">
  <datatypedef>
    <datatypearg order="1">
      <datatypedef name="varchar">
        <datatypearg order="1" value="25"/>
      </datatypedef>
    </datatypearg>
    <datatypearg order="2" value="10"/>
  </datatypedef>
</fielddef>

and an int4:
<fielddef name="myint" type="int4"/>

You will note that:
* the structure is recursive (which means it is possible to create arrays of
arrays, etc)
* if there is a 'datatypedef' element in the 'fielddef' element, then there is
no need to specify its name as it is already done for the 'fielddef' element.

What do you think of this structure?

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

No, the sequence element is intended to save a sequence object (to make a
backup)! What I would like with the XML queries is to be able to do ALL one can
do with SQL (or other similar languages). But it does not mean that
the same XML query can be executed by two different DBMS (because of the
contents), in the same way that two different DBMS which understand SQL92 won't
be able to run the same SQL queries (again because of the contents).

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

I hope you understand better (if my english can be understood!) what my point of
view is for the XML queries.

Regards,

Vivien