VOTable alternative & "Dataset.xml"
ael at star.le.ac.uk
Mon Jan 19 13:23:36 PST 2004
I guess if you really need to bundle the metadata and the data then you can
wrap them in some envelope document - schema followed by data - or transmit
both separately. But each would still be in normal xml form. You would still
have to generate the schema from the schemas of the originating tables but I
guess you have to do that with the existing VOTable and doing so from
schemas should be easier. )(Though I still find the namespacing solution
simpler and neater.)
> -----Original Message-----
> From: Alasdair Allan [mailto:aa at astro.ex.ac.uk]
> Sent: 19 January 2004 21:11
> To: Tony Linde
> Cc: votable at ivoa.net
> Subject: RE: VOTable alternative & "Dataset.xml"
> > But if the metadata for a table is available in some
> standard way (eg
> > in the registry)...
> Thats fine, but what if the meta-data isn't in the registry,
> or what if you're using the VOTable (or whatever XML document
> we're talking about
> now!?) to do service to service communication. What if both
> these services are fairly low level? Are we going to make
> (demand) every service is registry aware? Surely that's going
> to be a massive overhead we want to avoid?
> > ...then is it not possible for the results of a query to simply
> > _reference_ the original table's metadata (via namespacing
> perhaps)? A
> > join could reference the metadata from all the tables involved with
> > equivalent namespaces.
> Yes, but! What happens to simple at this point? While its an elegant
> enough idea if we start to get too complicated the astronomer on the
> street is going to just not use our stuff.
> The real problem VOTable solved (for me) was having the
> meta-data just
> there, with the data (or at least with a URI pointing to the
> raw data).
> Putting the meta-data somewhere else seems to totally defeat
> the purpose,
> at least from my point of view....!?
> > Biggest drawback is having the metadata to hand but ubiquitous
> > registries should take care of that.
> Yes, but! Ubiquitous registries is all very well, but we need "simple
> services for simple tasks", we should be doing things as simple as
> Demanding every service has to be able to talk to the
> registry to pull back meta data for catalogue queries would
> not be good. It would also double the number of network calls
> (every service you passed this document to might have to talk
> to the registry! ick!).
> > How does that sound?
> Err, I'm not convinced!
> Dr. A. Allan, School of Physics, University of Exeter
More information about the votable