Re: [galeon] [WCS-2.0.swg] CF-netCDF standards initiatives

Hmmm. 
Putting definitions inline has the risk of encouraging invention rather than
re-use. 
Encouring the registration of standard definitions allows and encourages
re-use, which is more like standardization in my book. 


--------------------------------------------------------
Simon Cox

European Commission, Joint Research Centre, 
Institute for Environment and Sustainability, 
Spatial Data Infrastructures Unit, TP 262 
Via E. Fermi, 2749, I-21027 Ispra (VA), Italy 
Tel: +39 0332 78 3652
Fax: +39 0332 78 6325
mailto:simon.cox@xxxxxxxxxxxxxxxx 
http://ies.jrc.ec.europa.eu/simon-cox 

SDI Unit: http://sdi.jrc.ec.europa.eu/ 
IES Institute: http://ies.jrc.ec.europa.eu/
JRC: http://www.jrc.ec.europa.eu/
--------------------------------------------------------

-----Original Message-----
From: galeon-bounces@xxxxxxxxxxxxxxxx
[mailto:galeon-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Robin, Alexandre
Sent: Friday, 21 August 2009 11:01
To: Tom Whittaker
Cc: Ben Domenico; Unidata GALEON; wcs-2.0.swg
Subject: Re: [galeon] [WCS-2.0.swg] CF-netCDF standards initiatives


Hi Tom,

No you're not out-of-lie at all. I'm glad you pointed out this problem.

Sorry for this example, I did not notice the xlink pointing to the record
out of band.

According to the SWE Common standard, metadata can very well be put inline
in the XML along with the encoded data. Actually this is the recomended
approach.

I personally disagree with the approach of externalizing the record
definition. This is inspired of the GML CRS spirit but I personally don't
like it for the reason you mentioned. It is there because some communities
like to register well known types of data structures for reuse...

Attached is the more "standard" version of doing this in SWE Common. Sorry
for the confusion and I hope it will clarify and ease your fears of doing
the same mistakes again :-)

Just one more thing: This examples shows text encoding but SWE Common allows
raw or gzip/bzip compressed binary encoding as well. Since binary data
cannot be embedded in XML (except in base64 which is one option in SWE
Common), the binary data would have to be referenced from the XML
description, thus potentially causing the problem you fear.

IMO the solution here is to wrap both XML description and binary data
together in an existing packaging formats such as MIME (we do that at the
output of web services using SOAP w/ attachments for example). This package
can then be sent around without loosing track of the description.

This last point is still work in progress but the concept have been tested
successfully.

Regards,

-------------------------------------------------
Alexandre Robin
Spot Image, Web and E-Business
Tel: +33 (0)5 62 19 43 62
Fax: +33 (0)5 62 19 43 43
http://www.spotimage.com
Before printing, think about the environment



> -----Message d'origine-----
> De : Tom Whittaker [mailto:whittaker@xxxxxxxx] Envoyé : jeudi 20 août 
> 2009 18:55 À : Robin, Alexandre Cc : John Caron; Unidata GALEON; Ben 
> Domenico; wcs-2.0.swg Objet : Re: [galeon] [WCS-2.0.swg] CF-netCDF 
> standards initiatives
> 
> I may be ignorant about these issues, so please forgive me if I am 
> completely out-of-line....but when I looked at the examples, I got 
> very concerned since the metadata needed to interpret the data values 
> in the "data files" is apparently not actually in the file, but 
> somewhere else.  We've been here before:  One of the single biggest 
> mistakes that the meteorological community made in defining a 
> distribution format for realtime, streaming data was BUFR -- because 
> the "tables" needed to interpret the contents of the files are 
> somewhere else....and sometimes, end users cannot find them!
> 
> NetCDF and ncML maintain the essential metadata within the files:
> types, units, coordinates -- and I strongly urge you (or whomever) not 
> to make the  "BUFR mistake" again -- put the metadata into the files!
> Do not require the end user to have to have an internet connection to 
> simply "read" the data....many people download the files and then 
> "take them along" when traveling, for example.
> 
> If I simply downloaded the file at
> <http://schemas.opengis.net/om/1.0.0/examples/weatherObservation.xml>
> I would not be able to read it.  In fact, it looks like even if I also 
> got the "metadata" file at:
> <http://schemas.opengis.net/om/1.0.0/examples/weatherRecord1.xml>
> I would still not be able to read it, since it also refers to other 
> servers in the universe to obtain essential metadata.
> 
> That is my 2 cents worth....and I hope I am wrong about what I saw in 
> the examples....
> 
> tom
> 
> --
> Tom Whittaker
> University of Wisconsin-Madison
> Space Science & Engineering Center (SSEC) Cooperative Institute for 
> Meteorological Satellite Studies (CIMSS)
> 1225 W. Dayton Street
> Madison, WI  53706  USA
> ph: +1 608 262 2759