Hi Ben:
On Oct 8, 2008, at 3:44 PM, Ben Domenico wrote:
Hi Jon,
I think you've cut right to the heart of the matter again. Namely
your question: "How does this translate into interoperable
software?" That's a good way to ground the discussion for the
upcoming joint session at the OGC TC meeting where we will try to
determine how the OGC Coverages and Sensor Web Enablement (SWE)
thrusts fit together. (Note that Observations and Measurements O&M
conceptual framework is part of SWE).
I think it goes beyond that. Our experience so far with some of these
standards is that while they seem really neat and theoretically pure
on paper, they are almost impossible to translate into actual code. or
when you do the code is very complex and the service is very slow.
Just for laughs, go through the archive that existed for when John C.
was developing the WCS for THREDDS. There were many of the same
concerns - the devil is in the details with many of these when you try
to actually code it. We are running into similar problems trying to
write a general client for the IOOS SOS service.
I was not being flip when I mentioned Google. Google understands that
first and foremost services must be fast, easy to use, easy to
understand, and easy to program. I am concerned that as a community we
too are moving away from services that are relatively fast and easy to
use, to those that are extremely complex and difficult to understand
- and I would re-ask one of the original questions that started all of
these threads - what is it that is being gained by all of the added
complexity? Interoperability is often mentioned, but as you can see
from some of these discussions (and I think is was Peter Baumann that
mentioned this) it is interoperability only in theory, you could never
write a client that can deal with all of the cases.
My $0.02.
-roy
