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



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.

> ...
> <!ELEMENT func (field|const|func)*>
> <!ATTLIST func 
>           name  NMTOKEN #REQUIRED
>           alias NMTOKEN #IMPLIED>
>
> ---------> Add the aggregate attibut as you mentionned it. It was a better idea
> than the aggregate element!

Done.

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

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

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


Gerhard






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]