Mapping ADQL - XQuery

[Ray Plante]

On Thu, 19 May 2005, Tony Linde wrote:
> The point really is that we need, in the RI, to specify how identifying an
> element in the ADQL WHERE clause that we use for simple searches translates
> into identifying the appropriate element in the metadata for a resource. 

I think we can do this.  

A clarification on Tony's example:

  <a>
    <b>
      <c/>
      <c/>
      <c/>
    </b>
  </a>

> identifying an element we have '[/a/b/c]=99' but which of the c elements are
> we checking for having the value 99? Ray implements it as 'any c = 99', but
> equally valid is 'all c = 99' or 'first c = 99' etc. 

We are sssuming you mean 'any /a/b/c = 99', that is a "c" within a "b" 
within a "a".  

> The second place where this ambiguity occurs is '[/a/b/c]=99 AND
> [/a/b/c at x]="Y"' (i.e. 'element c = 99' AND 'attribute x of element c has
> value "Y"'): does this mean (if we assume 'any' as the answer to the above
> question)
>  'any element c = 99' AND 'any attribute x of any element c = "Y"' or
>  'any element c = 99' AND 'the attribute x of the same element c = "Y"'

This is clearly a short-coming of the ADQL approach.  It arises with any
repeatable, complex type.  We have a number of examples of these;  
however, the only ones worth worrying about are relationships and the type
that will contain validationLevel.  The implied mapping of ADQL to
VOResource (which needs to be made explicit in the spec) is a flattening
of the VOResource structure to a single "virtual" table, as it were.  To
do handle this case would require:

  1. effectively mandating the underlying table model that is used in the 
     implementation
  2. The inclusion of a FROM clause where different levels/objects are 
     defined for the query.   

Kevin's point that the shortcoming only causes more records than desired 
to be returned, rather than causing desired records to be missed.  This is 
consistent with the prevalent philosophy in our projects regarding fuzzy 
searches.  Relationships and validationLevel may provide us with the 
motivation to support more capable query mechanisms.  With the 
inclusion of optional support for XQuery, which gets around this problem, 
we have a trajectory for migrating to something more capable that is 
driven by actual use.  

cheers,
Ray