ael at star.le.ac.uk
Tue Jan 20 22:05:32 PST 2004
Now I am confused again. I thought your V2 proposal was to split the
metadata from the data but in a way that could be generated from and
transformed back into VOTable. I have no objection to the layout
presented which seems a logical evolution of VOTable but I think we need
a proper separation of metadata and data to achieve compliance with the
spirit of xml.
Taking your v2.txt, we can see the contents of XMLDATA being moved into a
separate file, results.xml, say. We then need to *fully* describe that
data in a schema file, results.xsd.
The schema, results.xsd, would contain all the information in the
V2/VOTable header as presented, but in a way that makes it a fully
compliant xml schema.
In order to be able to create this xsd, we need to define the schema
language that we will use. This should be an extension of the xml schema
language definition (the xml 'metaschema'). It is here I think that most
of the work needs to be done.
As an example, does an element in a VO record get described as an
xsi:element construct which we have extended to include attributes like
ucd, or do we create a new 'field' construct which fully inherits from
xsi:element and to which we attach the ucd attribute. Ie, does the
results.xsd contain <xsi:element xsv:ucd="ID_MAIN" type="xsi:string"> or
<xsv:field xsv:ucd="ID_MAIN" type="xsi:string">.
(where xsi: indicates usage from the xml schema and xsv: indicates usage
from a VO schema which we will develop as an extension of xml schema)
NONE of this will invalidate VOTable or is meant to replace it. I want to
see us develop a format which is fully compliant with the letter and
spirit of xml but allows us to retain VOTable as a single document
transport mechanism (whether or not it evolves into the V2 structure).
One additional benefit here is that the 'metaschema' which we define can
be used by data centres to describe their data holdings such that these
descriptions can be included in the registry entry for each dataset *and*
can be used as the basis for generating the VOTable header for queries on
and extracts from those datasets.
(Roy: sorry if this is what you meant and I've misunderstood again.)
On Tue, 20 Jan 2004 14:59:26 -0800, "Roy Williams" <roy at cacr.caltech.edu>
> Francois and Tamas
> If I could present to you the first rough view of a V2 document
> that was prepared by Matthew Graham. But we have had no time to verify
> please just try to read it to see what is proposed.
> It is *very* similar to VOTable. You need to look carefully at the data
> section to see the differences. But I think it is "hardXML" enough to
> automatic validation, automatic code generation from WSDL, etc etc.
> it can be converted to MS Dataset also.
> Comments welcome
> Caltech Center for Advanced Computing Research
> roy at cacr.caltech.edu
> 626 395 3670
Phone: +44 (0)116 223 1292 Mobile: +44 (0)7753 603356
Fax: +44 (0)116 252 3311 Email: ael at star.le.ac.uk
Post: Department of Physics & Astronomy,
University of Leicester
Leicester, UK LE1 7RH
Project Manager, Director,
AstroGrid Leicester e-Science Centre
More information about the votable