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