NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
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
galeon archives: