At the GITA conference, Mark Doherty of Intergraph raised an interesting point in his presentation. He compared commonly accepted standards as proposed for the OGC, for example, versus "defacto" or perhaps more commonly "used" standards that may be neither "open" (in the current vernacular) nor a true standard. His examples recognized WMS and WFS as an example of common specifications. While the analogy is not quite accurate, his "defacto" standard was the use of Oracle Spatial as a platform more commonly chosen to manage spatial data. You might think of KML as another "defacto" standard for sharing data on the Google platforms.
It raises an interesting point of whether some standards or specifications are too fleeting; here today but fade when the market determines something different. And how does someone with the responsiblity of developing an enterprise architecture decide.
.gif&contenttype=gif)
What's your user base? Who will work with the system? HOW will they use the system? The new geoexploration tools have virtually all the functions the casual user ever asks for (hey, just put it on a map, fer cripes sakes) without all the absurd implementation budgets.
Then again, if you're building parcels, you'd better be working in serious precision...
Oracle is a system and in my opinion not relevant for this discussion.
kml is an exchange format and might indeed be a candidate for being promoted from defacto to accepted (as is already being discussed by OGC).
Selecting a system architecture like Oracle is an internal discussion and depends on the knowledge of technical staff, costs of ownership and maintenance and stability.
I will actually post twice. First, we must understand what is meant by "de-facto" and by "de-jure". From wikipedia, which truly has an excellent definition of these terms:
De facto is a Latin expression that means "in fact" or "in practice" but not spelled out by law. It is commonly used in contrast to de jure (which means "by law") when referring to matters of law, governance, or technique (such as standards), that are found in the common experience as created or developed without or contrary to a regulation. When discussing a legal situation, de jure designates what the law says, while de facto designates action of what happens in practice.
Now, in the Geospatial community, the shape file format, KML, and GeoRSS are de-facto standards. In contrast, the OGC Web Map Service (WMS) Inteface defintion is a de-jure standard. This is because it is also an ISO standard. ISO standards are de-jure standards.
Now, to just make the discussion a bit more interesting, WMS is also a de-facto standard because it is also heavily used in practice. The point being that just because one has a de-jure standard does not mean that it will be implemented. Conversely, a de-facto standard can also become a de-jure standard. This is the case for KML 2.2. The OGC membership is in the process of approving KML 2.2 as an international standard.
More tomorrow on the issue of standards and "transience" due to rapid market changes.
Regards
Carl
I don't disagree with you on principle (de jure
It raises an interesting point of whether some standards or specifications are too fleeting; here today but fade when the market determines something different.
I would counter that standards provide a very high level of stability in a constantly changing environment. Consider the standards upon which the internet and web are built. Some of these key standards have been with us for 10 years or longer. For example, HTTP emerged as an informational RFC in 1996 and evolved through 1999 but has been quite stable since then (http://www.w3.org/Protocols/History.html). While these standards may evolve slightly to accommodate lessons learned or new requirements, they remain relatively stable thus allowing web and enterprise applications to emerge, change, prosper, die, and so forth as market requirements dictate. Standards and standards based applications also enjoy lowered risk and greater agility in responding to changing market forces.
Without the stability that standards provide, we would not have the dynamic and creative Web 2.0/Where 2.0/LI environment we enjoy today.
Regards
Carl
A bit off topic, but . . .
"GML vs KML" is not a totally accurate approach to this discussion. You must consider the design objectives and the problems that each of these XML grammars is attempting to solve. GML is intended as an XML grammar for encoding and communicating features. GML is grounded in ISO 19107 (Features) as well as other ISO standards. As such, GML can be used to express very simple geo content (as in GeoRSS GML) or very semantically and geometrically rich content (as in CityGML). KML, on the other hand, evolved to solve a totally different problem domain: the expression of relatively simple location based content in an earth visualization environment. By relatively simple, I mean that KML was not designed to handle all possible geometry or graphics types that are currently used in the geo community. Therefore, many view GML and KML as complementary and not in "competition". As always, use the right tool!
Regards
Carl