Hi Peter, all,
Peter Baumann wrote:
looks like we "wildly agree" (nice term I learnt recently): in a
GetCoverage response there is the coverage payload + metadata. I do
like the idea of having a canonical + complete metadata set in XML
(ok, GML) I also have advocated that, in case the server erroneously
puts divergent metadata into format header and XML, the XML data prevail.
Quite some folks alternatively want to have a "stripped" response
without XML and MIME encapsulation (or whatever), though. That's where
we have to live with incomplete metadata then - but IMHO this is a
user's informed decision then. Va bene.
I don't see that the "stripped" or "single file" response necessitates
incomplete coverage metadata. It depends on how well (and complete) a
particular coverage format encoding document maps the coverage metadata
into that format. Which of course, also depends on the capabilities of
that format for capturing all the coverage metadata.
A complete mapping may not be an easy goal for many formats. But it
seems an important goal for the format encoding documents to map as
completely as possible both the payload and the metadata into the target
format in a way that is natural to that format. Having the metadata fit
naturally into a format means that the tools that already deal with that
format will have an easier time accessing (and hopefully understanding)
the metadata.
Ethan
--
Ethan R. Davis Telephone: (303) 497-8155
Software Engineer Fax: (303) 497-8690
UCAR Unidata Program Center E-mail: edavis@xxxxxxxx
P.O. Box 3000
Boulder, CO 80307-3000 http://www.unidata.ucar.edu/
---------------------------------------------------------------------------
