VOTable alternative & "Dataset.xml"

[Tony Linde]

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.)

Cheers,
Tony. 

> -----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 
> possible.
> 
> 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!
> 
> Al.
> -- 
> Dr. A. Allan, School of Physics, University of Exeter
>