NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
Hi Simon, Agreed that it can be a good thing for certain communities. It can help building a-priori knowledge about the data stream that a consumer could expect. It's especially useful for simple clients that don't necessarily have the resources to discover this on-the-fly. But SWE Common is also here to be self describing so that only the semantics really need to be registered and reused. Everything else can be dynamically parsed. In other words it is not always necessary to standardize everything at the syntactic level details if the encoding self-describes parts of its syntax... (which is the case of SWE Common) 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 : Simon Cox [mailto:simon.cox@xxxxxxxxxxxxxxxx] > Envoyé : lundi 24 août 2009 09:30 > À : Robin, Alexandre; 'Tom Whittaker' > Cc : 'Ben Domenico'; 'Unidata GALEON'; 'wcs-2.0.swg' > Objet : 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
galeon archives: