A few questions

Kevin Benson kmb at mssl.ucl.ac.uk
Thu Jul 8 11:56:32 PDT 2004


Great Thanks Ray and Matthew.

Matthew makes a good point with the "[]", I think originally we just did
not want to allow filtering a particular number of results /Resource[3] or
/Resource[3,4].  Even though obiviously as using an xmldb with xpath and
xquery it won't give any problem if we decide to put back in the "[]".

I will let you put in that OwnedAuthority it should be the same as
ManagedAuthority.

I agree with your number #1, just sort of new to ADQL so I am trying to
catch up of the various search elements after the where clause.

For the prefixes.  I sort of like the vr:interface/vs:result=... best and
prefer this.(#2).
We could also do as you say no prefixes #3 interface/result=...  But this
does sometimes have a side effect on xmldb's because your query needs to
handle namespaces hence your query may come out to being
*:interface/*:result=...  and the "*:" I have seen slightly slower queries
on this, plus like Matthew's statment there are a couple of elements that
could be a problem like facility.  So #2 sounds the better way.

Logging off till morning; thanks for your help, probably be good to keep
replying to determine if we will handle the "[]" and to make certain that
we will keep predefined prefix's.

Thanks again,
Kevin

On Thu, 8 Jul 2004, Ray Plante wrote:

> Hey Kevin,
>
> On Thu, 8 Jul 2004, Kevin Benson wrote:
> > 1.) In the ADQL schema I see there are various types of searches for a
> > Where clause, ex: function searches, comparison searches, predicate,
> > xmatch and others.   Are we going to support all of them?
>
> I need to crack ADQL and my examples open again to come up with an exact
> recommendation which will take a few minutes.  In general, however, a
> judicious decision has to be made regarding what we put in the WD, what we
> actually implement in this first round, and what we leave out for now.
>
> XMatch should be left out as it is not logically applicable.  Function
> criteria will be important (e.g. for STC/region support) and should be
> included in the WD spec; however, I don't recommend we try to support it
> in this next round.  Everything else, if I recall correctly is just simple
> SQL and therefore should be included.
>
>
> > 2.) We said it would be XPath.  How do we want to handle Namespaces?  Are
> > we going to use predefine prefixes such as "vs:" for some of our
> > extenstions meaning the data service namespace.
>
> This is a detail we have not addressed.  Our options are:
>
>   1. we do things the proper XML way:  the ADQL query itself defines the
>      prefixes it will use.
>
>   2. we mandate the use of predefined prefixes:
>
>         vr:interface/vs:resultType='text/xml+votable'
>
>   3. we just not included (in this round) namespace prefixes in our
>      xpath-based queries, e.g.
>
>         interface/resultType='text/xml+votable'
>
> 2. and 3. are intended to be simplifications that might be make things
> easier.  If not, we should go with 1.
>
> > 3.) I think we said we were not going to handle xpath functions correct?
>
> Correct.  Furthermore, we do not allow [] in our paths.
>
> > 4.) Ray or was someone else doing a xsl stylesheet for converting v0.9 to
> > v0.10?
>
> We have prototypes done--I'm testing them now.
>
> > 5.) Ray do you want me to add the <OwnerAuthority> element for the
> > Registry type Resource?
>
> I believe this was indeed one of the items we resolved to include.  I'd be
> happy if you wanted to go ahead and send me a modified version of the
> VORegistry schema.  Otherwise, I can do it.
>
> cheers,
> Ray
>
>
>






More information about the registry mailing list