VODataService becoming WD, then PR

[Gerard]

Hi Ray

> 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.
> 
A foreign key is a relation from one table to another (well, sometimes the
same) table.
Hence IF we want foreign keys in the model, a definition at the table level,
not the column level is most natural. A solution like the noe above seems to
me simple enough to support the feature that sometimes keys are composite. 

Note also that sometimes one of the columns in such a composite foreign key
is part
of another foreign key. This especially happens in
grandparent<-parent<-child<-etc relationships.

A TAP inspired example could be the Database<-Schema<-Table<-Column
relations in the TAP_SCHEMA,
ff this were modeled as follows

TAP_SCHEMA.databases
name
...
primary key(name)


TAP_SCHEMA.schemas
database_name
name
...
primary key(database_name, name)

TAP_SCHEMA.tables
database_name
schema_name
name
...
primary key(database_name, _schema_name, name)

TAP_SCHEMA.columns
database_name
schema_name
table_name
name
...
primary key(database_name, _schema_name, table_name, name)

Fore xample TAP_SCHEMA.columns has a foreign key (database_name,
schema_name, table_name) to tables,
(database_name, schema_name) to schemas and database_name to databases
This further complicates a column-level definition of the foreign key.

Independent of that, I think one use case for explicit inclusion of foreign
keys might be the generation of HTML documentation (using XSLT for example)
for a tableset, with appropriate hyperlinks (in both directions) between
tables related via a foreign key. 

In the "simDB-browser" web app Laurent Bourges and I are developing for
browsing through the SimDB database, we use a similar feature for navigating
the database itself. We use the knowledge about foreign keys incorporated in
the metadata to generate appropriate queries to find all rows in the source
table pointing to a given row in the target table.

(In fact we do this at the object model level, using the Java Persistence
Architecture, but the concept is the same).

> 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.
> 
I see, that would simplify the model even further.

> more comment out there?
> 
Maybe again for a possible TAP extension:
Should/could indexes be included in the metadata for a table?
When composing queries it is often very useful to know what indexes exist.

Gerard