Re: ADQL WD v1.05

Yuji SHIRASAKI wrote:

>
>>(1) ADQL/x and ADQL/s.
>>
>>There are now two ways of specifying ADQL: BNF and XML schema. Although
>>you state "ADQL/s and ADQL/x are translatable to each other without loss
>>of information", does this apply to the specifications themselves?
>
>
> Yes.
>

I'm glad we agree that the ADQL schema and the BNF definition of adql should be equivalent. This is very important to our work on query building in Astrogrid. However, I find your view difficult to reconcile with ...

> If we put enumerations to the schema, It will become difficult to introduce
> new operator without updating the schema. I don't like to change the
> schema so frequently just for introducing the new operators.
>

...especially considering the enumeration of comparison operators and indeed functions within the BNF draft definition. How can you reconcile these views?

>>(2) Core and Extensions.
>>
>>The description of Core and Extensions I find somewhat misleading. There
>>appears to be no extension mechanism here. Rather, the specifications
>>represent some idea of core and some idea of full. I believe the ideas
>>of "extension" and "full" are somewhat different. A proper extensions
>>mechanism would surely be more flexible. I think to be consistent, if we
>>go along with this idea, one should talk of Core and Full.
>
>
> I don't understand why you say "no extension mechanis"....
> The FULL was used before the Victoria meeting, but it was decided to
> use a word "Extesion" for syntax beyond the Core.
>
>

It seemed to me that the schema for Full will simply be different from the schema for Core, rather than a superset. Are we saying that the definitions in the Core schema will be contained unchanged in the Full schema? Again, this is of considerable interest to our work in Astrogrid, as otherwise we will need to somehow duplicate xslt stylesheets AND generate different frameworks for the two disimilar specifications. (The structure does not have to differ by much to make things incompatible).

>>(3) Core: From clause.
>>"Exactly one table SHALL be specified in the FROM clause. A table is
>>specified by a table name followed by an alias name. The table alias
>>name MUST be supplied."
>>I'm sorry I need clarification here. Are you suggesting only ONE table
>>can be selected from in any one query?! In my opinion this is far too
>>restrictive even for a Core specification.
>
>
> Yes. only one table.
>
> Core spec is defined so that it apply all the enviroment.
> Some data might be stored on a text file, and query is implemented
> by just using a script. Some data might be store on a XML db, the
> main query is made by XPath but it allows an ADQL query. I don't
> think XML DB support table join thing.
>

These are implementation details interfering with the spec. If you have one table (one file) in your database, you can only at the most join it to itself. Why make a rule to say you cannot join it to other tables when they don't exist?

>
>>(6) Core: Region and Frames.
>>
>>"<frame> is a frame name defined in the STC specification". Will the STC
>>specification be a part of ADQL? In the previous XML schema, it was
>>quoted as an import. I found it of considerable use in driving region
>>queries.
>
>
> ADQL schema import STC schema, but only a small part of the STC schema
> is used.
>

Wonderful. I thought you were implying the ADQL schema would not be importing the STC schema.

Regards
Jeff

-- 
Jeff Lusted                tel: +44 (0)116 252 5358
AstroGrid Project          mob: +44 (0)7973 492290
Dept Physics & Astronomy   email: jl99-at-star.le.ac.uk
University of Leicester    web: http://www.astrogrid.org