Query message format

[Tony Linde]

Hi Ray,

> I would suggest that an XML-encoded query format need not be less rich

> than XQuery.  It could be defined to allow lossless transformation
back 
> and forth.

I guess that's possible but given the syntax, functions, operators etc,
I think it'd be extremely difficult to replicate every possible
construct within XQuery as a tag in some xml structure.

> database.)   My questions about XQuery would be: who typically will
accept 
> XQuery queries?  Those that can already accept them natively, or will 
> people have build parser/translaters a la SIA?  Is the XQuery parsing 
> problem escapable?  

I doubt anyone would be looking to build an XQuery parser to some old or
complex format - it'd be easier to convert the data into XQuery-able
format. Those who in 2-5 years time will be able to accept XQuery will
be anyone storing data in xml form obviously plus anyone using any of
the major rdbms (IBM, Microsft, Oracle etc), all of whom will shortly
have native XQuery capability.

>    1.  A user forms a single query that will be transmitted to
multiple 
>            repositories.  This necessitates the use of standard
metadata
>            that all of the repositories support.

What is needed is the lowest common denominator, but if they all support
the richest query form then that should be allowed.

> In general, I don't see this legacy issue ever going away.  

Agreed. But I suspect the major data sources (the newer ones at least)
will be based on the major rdbms's so in 2+ years, XQuery is likely to
be pretty much acceptable tender in all the major data centres.

> simpler querying protocol that clients need to support.  So one last 
> question about XQuery:  what fundemental capabilities of XQuery make
it 
> useful as an interchange format?

In my reading it seemed that XQuery was being positioned to become a
defacto standard for querying from any type of structured data storage.
It seemed pointless for us to come up with something that did not at
least use XQuery as its starting point.

Cheers,
Tony. 
  

> -----Original Message-----
> From: Ray Plante [mailto:rplante at poplar.ncsa.uiuc.edu] 
> Sent: 18 February 2003 16:48
> To: voql at ivoa.net
> Subject: Re: Query message format
> 
> 
> Hi Tony,
> 
> > > In my opinion, the most important requirement of the query 
> > > interchange format is that it be easily converted into 
> other forms.
> > 
> > Or, to restate, that it can be parsed and applied to different data 
> > stores? But it'd probably be more time consuming to write 
> parsers for 
> > XQuery than translators of some XML format.
> 
> Yes, that is essentially correct.  
> 
> > Perhaps we need a 2-tier VOQL: if the metadata for the all datasets 
> > being queried says that they can all accept XQuery format queries, 
> > then the user formulating the query has a rich interface but if any 
> > does not have that, then the query format and interface is 
> reduced to 
> > cope.
> 
> I would suggest that an XML-encoded query format need not be 
> less rich 
> than XQuery.  It could be defined to allow lossless 
> transformation back 
> and forth.  (The tricky part is bridging the relational--OO 
> divide.  That 
> is, a query may be destined for both an SQL RDBMS and an XML-based 
> database.)   My questions about XQuery would be: who 
> typically will accept 
> XQuery queries?  Those that can already accept them natively, or will 
> people have build parser/translaters a la SIA?  Is the XQuery parsing 
> problem escapable?  
> 
> That doesn't mean we shouldn't allow the definition of services that 
> accept XQuery.  As a general interchange format, we should 
> consider where 
> the query will typically end up.  If they will be compared agains XML 
> data structures, then it makes sense.  However, I don't see 
> XML structures 
> or databases overtaking RDBMSes anytime soon.
> 
> I like to model the query situation as a continuum between 
> two use cases:
> 
>    1.  A user forms a single query that will be transmitted 
> to multiple 
>            repositories.  This necessitates the use of 
> standard metadata
>            that all of the repositories support.  The 
> repositories must 
>            translate the standard metadata and query into a 
> form its DB
> 	   can handle.  This is the model of the NVO cone search spec.  
>            A mediator in the middle may be needed to do some 
> massaging of 
>            the query according to the repositories' capabilities.  
> 
>    2.  A user forms a query that will go to a single 
> repository.  This 
>            query can make use of custom metadata specific 
> only to that 
>            repository which they can advertise through a registry or 
>            "explain" service.
> 
> We can imagine something in the middle in which a query includes both 
> standard and custom metadata.  Some of the standard metadata may be 
> supported by only some of the repositories queried.  The SIA 
> goes part way 
> to addressing the middle ground: it defines standard query 
> metadata but 
> also allows implementations to advertise its own custom inputs.  
> 
> > > * an ASU query to an ASU interface
> > > * an SIA query to an SIA interface
> > > * a JVO query to the JVO grid.
> > 
> > I don't know these. Isn't ASU an intermediate query interface which 
> > VOQL would supplant? And SIA is still a proposal and will 
> presumably 
> > be amended to fit the standards? What is JVO?
> 
> Clearly, the SQL & XQuery cases are most important.  Yes, ASU 
> is meant to serve the same role, and yes, I would expect SIA 
> to be amended.  (The JVO project is prototyping a query 
> language, JVO QL.)  The point is that 
> services exist today that support these interfaces.  Some 
> providers can 
> choose to update as soon as a standard emerges; however, some 
> may not.  We 
> can deal with this through a query mediator which has access 
> to a registry 
> that, as you suggested, understands the capabilities of the 
> various query 
> services and can adapt the query accordingly.
> 
> In general, I don't see this legacy issue ever going away.  
> Our standards 
> will inevitablly change.  We don't want to resist needed 
> change because we 
> will leave lots of services out in the cold.  This is one 
> area where query 
> translation becomes important.
> 
> > I don't think there'll be an 'AstroGrid' to be outside of. More a 
> > matter of those data centres which choose to use some of 
> the AstroGrid 
> > components (possibly mixed with those from NVO, home grown 
> ones etc.).
> 
> I agree completely.  (You mentioned, though, the need to make 
> a choice 
> now, I gathered driven by current AstoGrid targets.)
> 
> > One component of any VO will be a query construction 
> interface (part 
> > of whichever portal or client the user chooses). This 
> interface will 
> > know which data sources are being addressed by the query 
> and will have 
> > to decode from what the user has entered into the interface 
> into forms 
> > acceptable by the data sources themselves.
> 
> It would be best to try push as much of the query mediation as 
> possible onto portals rather than end-user client apps.  This 
> would mean a 
> simpler querying protocol that clients need to support.  So one last 
> question about XQuery:  what fundemental capabilities of 
> XQuery make it 
> useful as an interchange format?
> 
> hope this help,
> Ray
> 
> 
> 
>