|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: GISList: Re: Effective Standards |
| Date: |
04/29/2003 04:25:00 PM |
| From: |
Dimitri Rotow |
|
|
> Interesting point, per usual. And an interesting example. In the recent
> era, it might be argued that standards which are accompanied by an open
> source reference implementation take off extremely quickly. Where would
> XML be without the early availability of Expat?
Exactly where it is today. I have never heard of "Expat" but I have heard
of Microsoft. XML became real when Microsoft made available a Microsoft XML
parser to the hundreds of thousands of developers who work with Microsoft
tools. Having a usable XML within Microsoft's standard development
environment is what allows Windows applications, which have a real impact on
whether something is a "standard" or not, to support it within mass markets.
> Where would MP3 be
> without the ISO reference source code? Provide an open source
Likewise, an irrelevant thing that had no effect on MP3 being adopted by the
masses. MP3 was made real by WinAmp and a proprietary codec. To the best
of my knowledge, not one of the mass-market tools that made MP3 real used
any "ISO reference source code."
> programmatic interface to the standard capabilities you want to provide
> and you are off to the races. I don't care about the Java RMI wire
> protocol language, because I can just call RMI functions. I don't care
> about the Oracle SQL*Net protocol because I can just call C functions.
> If OpenGIS wrote a binary client/server specification that included a
> BSD-licensed reference implementation library it would be immediately
> (a) useful and (b) used.
Used? Not likely, considering that most GIS is not done on UNIX - it's done
on Windows. Writing an implementation for BSD or other UNIX flavors is
simply consigning the would-be standard to irrelevancy. Those vendors who
do real volume and want to have something that most users want to buy will
write exclusively for Windows.
> All this hooey about XML/GML being "human
> readable" is irrelevant in the presence of a useable (and implemented)
> API.
Well, I agree with you that "hooey" and "XML/GML" should appear together,
but would point out that the "human readable" bit about XML/GML is the kiss
of death from a performance perspective. That OGC types like to talk about
the "human readable" bit is evidence of their technological naivete, an
example of one of the many poor technical choices from OGC that prevent it
from being widely adopted as a "standard." But, there's already been a
thread on this list to that effect so I would refer interested parties to
the archives for that debate.
Regards to all,
Dimitri
To unsubscribe, write to gislist-unsubscribe@geocomm.com
________________________________________________________________________
GeoCommunity GeoBids - less than $1 per day!
Get Access to the latest GIS & Geospatial Industry RFPs and bids
http://www.geobids.com
Online Archive of GISList (and numerous others) available at:
http://spatialnews.geocomm.com/community/lists/
Setup a GeoCommunity Account and have access to
the GISDataDepot DRG & DOQQ Catalog
http://www.geocomm.com/login.php
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
