proposed VODataService changes

Guy Rixon guyrixon at gmail.com
Tue May 20 07:01:55 PDT 2008


I posted two versions of the schema. One has mandatory deep nesting.  
The other is partially flattened in that one doesn't need to write  
the catalog or schema levels in all cases. If something is in the  
default catalog and schema, just write it at the top level.

In the flattened schema, instances of CatalogService that have tables  
at the top level remain valid under the new schema. In fact, all  
service instances that were valid under 1.0 would be valid under 1.1.

Conversely, when one actually wants to express that table X is in  
schema Y and catalog Z, one actually writes nested elements that say  
that.

Cheers,
Guy

On 20 May 2008, at 14:46, Doug Tody wrote:

> On Tue, 20 May 2008, Ray Plante wrote:
>> There is at least one place I would recommend some flattening: I'm
>> wondering if we really need to capture the database schema as a new
>> element layer (<schema>) between a <catalog> and <table>.  Can we  
>> instead
>> do something like this?
>>
>>     <catalog>
>>       <name>The X survey catalog</name>
>>       <description>...</description>
>>       <table>
>>          <schema>...</schema>
>>          <name>...</name>
>>          <description>...</description>
>>          <column>...</column>
>>          <column>...</column>
>>          ...
>>       </table>
>>       <function>                      <!-- optional -->
>>          <schema>...</schema>
>>          <name>...</name>
>>          ...
>>       </function>
>>       <join>                          <!-- optional -->
>>          ...
>>       </join>
>>     </catalog>
>>
>> In this case, if the <schema> element is omitted, the default  
>> schema is
>> assumed.
>
> The above suggestion is also the way this is addressed in the SQL
> information schema.  Another option, which we were considering before
> there was mention of explicitly adding a separate "schema" element,
> is to include this information in the table name as in  
> "<schema>.<table>".
>
> 	- Doug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3006 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/registry/attachments/20080520/d2e0821a/attachment-0001.bin>


More information about the registry mailing list