VODataService becoming WD, then PR

[Paul Harrison]

On 2008-11 -17, at 15:38, Ray Plante wrote:

> Hey Paul,
>
> Thanks a 10^6 for having a look.
>
> On Mon, 17 Nov 2008, Paul Harrison wrote:
>> I have one immediate issue with the latest version of the  
>> VODataService schema/specification. I think that the table  
>> description should contain an explicit definition of how to specify  
>> foreign keys that define the relations between tables - these  
>> relations are, after all, fundamental to the way that the  
>> relational databases function, and it is impossible to do a multi- 
>> table query without this information.
>
> As you alluded, the <relationalJoin> element provoked some criticism  
> that led to it being dropped.  The most cogent argument was that  
> this was it was not shown effective in an existing prototype,  
> although the problem you mention is recognized (see item 6 under http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/VODataService#Proposed_Changes 
> , if you haven't already).
>
> One of the problems that has been cited is that primary and foreign  
> key matching is not always that simple; in particular, keys  
> sometimes span across multiple columns.  On the other hand, a simple  
> solution as you suggest may satisfy a majority of situations.

I believe that this sort of proposal also works for the majority  
(all?) of the multiple-column key use cases as well - this is because  
even with multiple column keys there is a one-to-one relationship  
between the referenced and the referencing columns, so all that is  
necessary is to put a fkey attribute on each of the referencing  
columns that points to the corresponding primary column and then  
assume if there are two(or more) fkey attributes in a referencing  
table that both point to the same table then both columns should be  
used in the join condition.

In general things are not as complex as they look for the SQL  
statements dealing with foreign keys, as all that we are wanting to  
specify is that there is a relationship - we do not need to specify  
anything about how the referential integrity behaves, because we are  
only interested in forming queries from this information.
>
>
>> I think that it is possible to come up with something much simpler  
>> - e.g an optional fkey attribute on a TableParam that points to the  
>> primary key by using the "table.column" syntax for the attribute  
>> value.
>
> As a means of prototyping such a solution, the document does provide  
> several mechanisms for extension (section 3.3.2).  Two that might  
> work include:
>
>  o  extending the TableParam type to add the additional metadatum as  
> an
>     element and invoking it with the usual xsi:type mechanism.
>
>  o  decorating the column element with an attribute from an external
>     schema; this is allowed because the TableParam type definition now
>     includes a '<xs:anyAttribute namespace="#other" />'.
>
>
> Nevertheless, I would like to hear more discussion on this.  May I  
> put out a call for comment on this specific issue?  It may help if a  
> specific proposal is recommended.  I don't want to slow the progress  
> VODataService, but if there is discussion about it, it would be  
> completely appropriate to have it extend into the official RFC  
> period if necessary.
>
> thanks,
> Ray
>

Dr. Paul Harrison
JBCA, Manchester University
http://www.manchester.ac.uk/jodrellbank