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