VODataService becoming WD, then PR

[Ray Plante]

Hey Gerard,

Thanks for jumping in.

On Mon, 17 Nov 2008, Gerard wrote:
> A question. Is this specification supposed to support all features required
> by TAP metadata?
> If so, does it make sense to allow adding SQL datatypes to column
> (TableParam) definitions?

The types that are there cover the types supported by VOTable, a required 
transport format.  It is not expected all types represented in a 
particular database instance will be covered with these types. 
Nevertheless, extension mechanisms--particularly one using the 
<dataType>'s extendedType attribute (section 3.5.3)--does allow one to 
express a more specific type.  The TAP standard could recommend some 
recognized values for this attribute.

Regarding keys...

> One could add to the XSD something like
>
>  <xs:complexType name="ForeignKey">
>    <xs:sequence>
>      <xs:element name="targetSchema" type="xs:string"/>
>      <xs:element name="targetTable" type="xs:string"/>
>      <xs:element name="fkColumn" type="vs:FKColumn" maxOccurs="unbounded"/>
>
>    </xs:sequence>
>  </xs:complexType>
>
>  <xs:complexType name="FKColumn">
>    <xs:sequence>
>      <xs:element name="fromColumn" type="xs:string"/>
>      <xs:element name="targetColumn" type="xs:string"/>
>    </xs:sequence>
>  </xs:complexType>

I'll suggest that the simpler the solution, the better it stands up to the 
"this needs to be prototyped" argument.  By prototype, I think this means 
that we can point to an actual use of this by an application.  The 
extension mechanisms hopefully provide a solution to the chicken-and-egg 
problem.

One minor comment.  Table names are required to be unique within an entire 
tableset and already include any schema (or catalog) names.  Thus, 
<targetSchema> would be superfluous.

more comment out there?

cheers,
Ray