VODataService becoming WD, then PR
rplante at poplar.ncsa.uiuc.edu
Mon Nov 17 09:58:55 PST 2008
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.
> One could add to the XSD something like
> <xs:complexType name="ForeignKey">
> <xs:element name="targetSchema" type="xs:string"/>
> <xs:element name="targetTable" type="xs:string"/>
> <xs:element name="fkColumn" type="vs:FKColumn" maxOccurs="unbounded"/>
> <xs:complexType name="FKColumn">
> <xs:element name="fromColumn" type="xs:string"/>
> <xs:element name="targetColumn" type="xs:string"/>
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
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?
More information about the registry