Sean Gillies (Posts about industry)https://sgillies.net/tags/industry.atom2023-12-31T01:26:23ZSean GilliesNikolaPrescient analyst or stopped clock?https://sgillies.net/2012/07/10/prescient-analyst-or-stopped-clock.html2012-07-10T00:00:00-06:002012-07-10T00:00:00-06:00Sean Gillies<p>body_html_template</p>On transparency in making standardshttps://sgillies.net/2010/02/15/on-transparency-in-making-standards.html2010-02-15T00:00:00-07:002010-02-15T00:00:00-07:00Sean Gillies<p>William Vambenepe points out some <a class="reference external" href="http://stage.vambenepe.com/archives/1261">familiar bugs</a>:</p>
<blockquote>
<ul class="simple">
<li><p>The mailing lists of DMTF working groups are confidential. Even a DMTF
member cannot see the message archive of a group unless he/she is a member
of that specific group. The general public cannot see anything at all. And
unless I missed it on the site, they cannot even know what DMTF working
groups exist. It makes you wonder whether Dick Cheney decided to call his
social club of energy company executives a “Task Force” because he was
inspired by the secrecy of the DMTF (“Distributed Management Task Force”).
Even when the work is finished and the standard published, the DMTF won’t
release the mailing list archive, even though these discussions can be a
great reference for people who later use the specification.</p></li>
<li><p>Working documents are also confidential. Working groups can decide to
publish some intermediate work, but this needs to be an explicit decision
of the group, then approved by its parent group, and in practice it happens
rarely (mileage varies depending on the groups).</p></li>
<li><p>Even when a document is published, the process to provide feedback from the
outside seems designed to thwart any attempt. Or at least that’s what it
does in practice. Having blogged a fair amount on technical details of two
DMTF standards (CMDBf and WS-Management) I often get questions and comments
about these specifications from readers. I encourage them to bring their
comments to the group and point them to the official feedback page. Not
once have I, as a working group participant, seen the comments come out on
the other end of the process.</p></li>
</ul>
</blockquote>
<p>GIS industry standards are made in just such a non-transparent members-only
environment. I used to subscribe to the OGC's "mass market" (private archive,
but open to subscription) list and tried to engage in some discussion there,
but soon realized that although messages from the principals were being
cross-posted there, they weren't subscribed themselves and didn't see any
responses. I also tried to submit comments to the formal channel and found it
to be <a class="reference external" href="http://sgillies.net/blog/884/commenting-on-ogc-wmts/">broken</a> (there's a year long gap in the archives: it could have broken for that length of time without anybody noticing). Now that it's fixed, you can see the public comment process
doesn't get much <a class="reference external" href="http://lists.opengeospatial.org/pipermail/requests/">use</a>.</p>
<p>Despite this, the OGC's standards enjoy almost absolute buy-in from non-member
GIS specialists, particularly those from the open source community who need
something – anything – to counter de-facto standardization on ESRI products.</p>What geo-intelligence failures?https://sgillies.net/2010/01/01/what-geo-intelligence-failures.html2010-01-01T00:00:00-07:002010-01-01T00:00:00-07:00Sean Gillies<p>Busy and having fun! And <a class="reference external" href="http://www.gotgeoint.com/archives/wishing-everyone-a-happy-and-prosperous-2010/">disgustingly glib</a> about it. The GEOINT community either can't see or won't face its role in the past decade of bamboozlement:</p>
<blockquote>
<p>Here we are on the precipice of a new decade. Where did this past decade go? They say time flies when you are having fun or really, really busy. For the GEOINT community, the past decade offered a mixture of both. Many believe, rightly so, that GEOINT came of age in this past decade. The confluence of technologies maturing, political/events (i.e. two wars) and natural disasters has created opportunities and challenges for both the private and public sector. And, as a result, we have seen both sides step up — creating solutions that are light years beyond what was happening ten years ago. And, as we have seen at the most recent GEOINT Symposiums, geospatial intelligence will continue to be the cornerstone for national defense. So, to this we would like to wish the entire GEOINT community a happy and prosperous New Years, as we head into another exciting decade.</p>
</blockquote>
<p>The past decade was a <a class="reference external" href="http://www.nytimes.com/2007/04/28/books/28kaku.html">slam dunk</a>, baby!</p>GeoWeb: utopia or dystopia?https://sgillies.net/2009/12/07/geoweb-utopia-or-dystopia.html2009-12-07T00:00:00-07:002009-12-07T00:00:00-07:00Sean Gillies<p>Somedays I have very mixed feelings about where the "GeoWeb" is <a class="reference external" href="http://www.galdosinc.com/archives/746">going</a>:</p>
<blockquote>
<p>Example 1: Intelligent Traffic Systems</p>
<p>Roughly translated: A million cars idling for 10 minutes will consume some
140,000 litres of gasoline. At the same time we have serious global problems
with climate change and local problems with air pollution. Why should this be
the case? The problem can be seen as one in which there is a lack of
communication between the vehicles and the road.</p>
<p>I interpret this to mean that the traffic systems should regulate the
highways such that this condition does not take place, or takes place much
less frequently. One of the functions of Intelligent Traffic Systems would be
to minimize the pollution generated by the use of the highway system. Of
course, he does not say how that might entail regulation of an individual’s
actions but one can easily imagine the vehicle being told it cannot enter a
particular section of the highway, or cannot even be taken out of the drive
way. What is key in Wen Jiabao’s remarks is that we can use technology to
help us understand the consequences of individual actions, and the
relationship between those actions and physical laws (”wisdom of the earth”).
We can choose to let a million vehicles idle on the highway, but in doing so
we cannot avoid the consequences for air pollution, and for damage to our
health and to the planet. What an intelligent traffic system might do then,
at the very least, is to make the linkage between actions and consequences
visible to all of us, even if it does not yet constrain those actions.</p>
</blockquote>
<p>I'm all for a "planetary nervous system", but the thought that it would sooner
or later be hooked up to a state-operated planetary immune system that
constrains our actions is a bit chilling, no? I'm probably to the left of many,
if not most, of my readers, but I'm not ready to be <a class="reference external" href="http://memory-alpha.org/en/wiki/The_Return_of_the_Archons_(episode)">of the body</a>. I suspect
it's going to be constant struggle to keep the "Wisdom of the Earth" from being
rigged against civil liberties.</p>
<section id="comments">
<h2>Comments</h2>
<section id="re-geoweb-utopia-or-dystopia">
<h3>Re: GeoWeb: utopia or dystopia?</h3>
<p>Author: <a class="reference external" href="http://www.cadmaps.com/gisblog">Randy George</a></p>
<p>Come on Sean, surely you already knew about the "Intelligent Traffic System?"</p><p></p><i>"The shepherd cries</i><p></p><i>The hour of choosing has arrived</i><p></p><i>Here are your tools"</i><p></p><a href="http://www.vanityfair.com/online/politics/2009/12/al-gore-the-poet-laureate-of-climate-change.html">Al Gore</a><p></p><p></p><p>Do you still wonder who Obama will appoint as the next Poet Laureate?</p><p></p><p></p><p>Believe me, I didn't make this up! Osip Mandelstam, Not!</p><a href="http://www.vanityfair.com/online/politics/2009/12/al-gore-the-poet-laureate-of-climate-change.html">Al Gore Vanity Fair</a></section>
<section id="re-geoweb-utopia-or-dystopia-1">
<h3>Re: GeoWeb: utopia or dystopia?</h3>
<p>Author: <a class="reference external" href="http://ambergis.wordpress.com">Kirk Kuykendall</a></p>
<p>Oh, the irony: Chinese teaching us the lessons of Adam Smith.</p><p></p><p>ITS will allow a market place to be built where we pay for the consequences of our actions, perhaps by combining congestion pricing with cap and trade. Clearly they want us to be more efficient so we don't fall behind on our payments.</p></section>
<section id="re-geoweb-utopia-or-dystopia-2">
<h3>Re: GeoWeb: utopia or dystopia?</h3>
<p>Author: Sean</p>
<p>Al Gore is our shepherd? Good grief; you don't have to be a believer to cringe hard at that one.</p><p></p><p>I've been meaning to follow up on your post about Atom-formatted Microsoft data, Randy. Interesting stuff, I hadn't been following that application.</p></section>
<section id="re-geoweb-utopia-or-dystopia-3">
<h3>Re: GeoWeb: utopia or dystopia?</h3>
<p>Author: Tom</p>
<p>In many places individual vehicles are already impractical or regulated out of feasible use and replaced by public transport - which is probably more constrained than the ITS, which would probably only be useful on congested commuter routes anyway.</p><p></p><p>There is a danger in using IT-based automation to turn economic and environmental levers wholesale into a pervasive "artificial gravity" though: for one thing it reeks of trying to solve a monolithic, too-hard problem wholesale with a mixture of theory and ideology. We know how that usually goes: some significant cost is</p></section>
<section id="re-geoweb-utopia-or-dystopia-4">
<h3>Re: GeoWeb: utopia or dystopia?</h3>
<p>Author: Tom</p>
<p>*cough* ignored</p></section>
<section id="re-geoweb-utopia-or-dystopia-5">
<h3>Re: GeoWeb: utopia or dystopia?</h3>
<p>Author: Sean</p>
<p>I just added "against civil liberties" to the tail of my blog post. I'd implied it from the start, but it's better made explicit.</p></section>
</section>Lessons of standardizationhttps://sgillies.net/2009/10/30/lessons-of-standardization.html2009-10-30T00:00:00-06:002009-10-30T00:00:00-06:00Sean Gillies<p><a class="reference external" href="http://www.innoq.com/blog/st/">Stefan Tilkov</a> tipped me off to Adam Bosworth's <a class="reference external" href="http://adambosworth.net/2009/10/29/talking-to-dc/">lessons learned in creating standards</a>:</p>
<blockquote>
<ol class="arabic simple">
<li><p>Keep the standard as simple and stupid as possible.</p></li>
<li><p>The data being exchanged should be human readable and easy to understand.</p></li>
<li><p>Standards work best when they are focused.</p></li>
<li><p>Standards should have precise encodings.</p></li>
<li><p>Always have real implementations that are actually being used as part of design of any standard.</p></li>
<li><p>Put in hysteresis for the unexpected.</p></li>
<li><p>Make the spec itself free, public on the web, and include lots of simple examples on the web site.</p></li>
</ol>
</blockquote>
<p>Bosworth goes into each of these in detail, I've only reproduced the first sentence.</p>
<p>I feel like we achieved these well for <a class="reference external" href="http://geojson.org">GeoJSON</a>. It's a simple, readable, precise, and stupid format. For example, coordinates are represented in [<cite>x</cite>, <cite>y</cite>] pairs instead of arrays of <cite>x</cite> and arrays of <cite>y</cite> like you'd implement for software optimized for performance. Stupid in that sense, but much more transparent. The lack of feature attribute schemas and feature classes also seems pretty stupid to some people, but that's fine.</p>
<p>GeoJSON focuses on serialization of basic GIS features. It doesn't create any new protocols. It doesn't require any new abstract models of the world. The spec is plain HTML with links so you can refer to sections when you throw the book at someone, short and sweet, has clear examples, and no bizarre click-through license agreement. Not everything in GeoJSON had a real implementation before publication, but most elements of it had several independent implementations.</p>
<p><em>Update</em> (2009-11-10): Dale Lutz has blogged this <a class="reference external" href="http://blog.safe.com/2009/11/simplicity-with-geospatial-standards/">too</a>.</p>Jack Camelhttps://sgillies.net/2009/05/21/jack-camel.html2009-05-21T00:00:00-06:002009-05-21T00:00:00-06:00Sean Gillies<p><a class="reference external" href="http://www.coloradoan.com/article/20090521/NEWS01/905210342/1002/CUSTOMERSERVICE02/New+computer+curriculum+targets+middle+schoolers">Apparently</a>, my oldest daughter will be given the ESRI koolaid in 6 years. Owning the GIS curriculum in US colleges isn't locking in future revenue streams enough already? At least her home-schooling in Python won't be totally wasted. Perhaps that's even the free and open-source technology the author is talking about: Python is certainly the most accessible language supported by Google and ESRI.</p>
<p>Via <a class="reference external" href="http://apb.directionsmag.com/archives/5817-Google-Docs,-ESRI-Technology-for-Colorado-Middle-Schoolers.html">Adena Schutzberg</a>, who reads the Coloradoan so I don't have to. <a class="reference external" href="http://en.wikipedia.org/wiki/Joe_Camel">Title reference</a>.</p>
<section id="comments">
<h2>Comments</h2>
<section id="re-jack-camel">
<h3>Re: Jack Camel</h3>
<p>Author: so sad</p>
<p>i'm so sorry ... everyday math .. and now this.</p></section>
</section>Philosopher's Stonehttps://sgillies.net/2009/04/23/philosophers-stone.html2009-04-23T00:00:00-06:002009-04-23T00:00:00-06:00Sean Gillies<p>Jeff Harrison <a class="reference external" href="http://carboncloud.blogspot.com/2009/04/ogc-web-services-common-and-community.html">tries</a> to flip the <a class="reference external" href="http://sgillies.net/blog/873/whats-the-beef/">alchemist</a> label back onto the web wonks:</p>
<blockquote>
<p>Maybe what we should be thinking about is how to advance GeoWeb platforms NOT as proprietary implementations using an alchemy of REST, JSON, RSS, KML - but as Community GeoWeb Platforms that combine international standard geospatial web services with Web 2.0 technologies.</p>
</blockquote>
<p>Nice try, but no. We agree about the proprietary flavor of some of the "GeoWebs" out there. Google, in particular, promotes a "GeoWeb" that is dominated by its proprietary browser and its proprietary search. Our role in this "GeoWeb" is to make KML files and expose them through sitemaps, increasing the value of Google's proprietary index in exchange for some return traffic through Google's proprietary browser. <a class="reference external" href="http://www.tbray.org/ongoing/When/200x/2008/04/09/Google-Users-API">Sharecropping</a>, in other words. Still, the OGC's SOA isn't appropriate for a "GeoWeb". There's no web there. Principles of web architecture, standard protocols like HTTP/1.1, and standard formats like JSON, Atom – and even KML – remain the way to geographically enrich the existing web.</p>REST vs SOAP at ESRI DevSummithttps://sgillies.net/2009/04/08/rest-vs-soap-at-esri-devsummit.html2009-04-08T00:00:00-06:002009-04-08T00:00:00-06:00Sean Gillies<p>Yesterday, I saw a lot of links to David Chappell's ESRI Developers Summit <a class="reference external" href="http://www.esri.com/events/devsummit/sessions/keynote.html">keynote</a>. I tried and failed to stick with the video, but I did read through the slides. They're largely good, but there are some errors. Before his presentation becomes canon in the ESRI user community, I'd like folks to consider:</p>
<p>The watering down of REST constraints on slide 14 into optional principles that you apply or not "whenever possible", and disregard for the hypertext constraint. In fact, there's no mention of the hypertext constraint at all in the slides. Does Chappell not understand it? Not believe in it? It's impossible to say from the slides; maybe he went into it more, live. At any rate, substitute "when you want certain derived properties" for "whenever possible" and you get closer to the essence of REST. If you want the property of cacheability, then you add the uniform interface and stateless communication constraints. If you want the property of loose coupling, you add the hypertext constraint.</p>
<p>On slide 18, Chappell fails to mention an option that's familiar to all of us even if we're not entirely aware of it: code on demand. The client library provided by the service can be downloaded by clients at the time the service is accessed. On demand. You're probably already using OpenLayers (or something like it) in a way that's close to an on-demand library for negotiating with a service. Chappell's second option on that slide, while useful enough, has very little to do with REST.</p>
<p>On slide 20, Chappell confuses REST with the half-baked "REST APIs" that don't use service descriptions or any sort of hypertext representations. If you stick to standardized representation formats, there's no more dependence on written documentation than in the SOAP case. Developers of SOAP tools had to read a pile of specs. Developers of RESTful HTTP tools will have to read a pile of specs too.</p>
<p>Finally, there's a lot of slides spent trying to explain how to choose between SOAP and REST. Ultimately, it comes down to this: if you want your system to have the properties that derive from REST constraints, you choose the REST style. If you want to integrate in the Web, you choose REST. If you want a system that tries to abstract away the network, letting your developers program with remote services as though they were local objects, you choose SOAP. Pick your architectural style. I don't think it has to be any more complicated than that.</p>
<p><strong>Update</strong> (2009-04-09): Pete (below) has shamed me into watching the video all the way through. I'm glad I did. I knew this stuff already, but it's a very good presentation for the ESRI user/developer. Unfortunately, despite Pete's claims, my quibbles with his slides stand. Chappell didn't cover the hypertext constraint (though he did an excellent overview of the wins from uniform interface and universal identifiers). An adequate treatment would have consumed too much time, granted, but some mention would be nice. The hypertext constraint has indeed been a matter of debate, but the wins are <a class="reference external" href="http://www.infoq.com/articles/webber-rest-workflow">becoming</a> <a class="reference external" href="http://tech.groups.yahoo.com/group/rest-discuss/message/12358">clear</a>. Without links in content, well-defined formats, and code on demand, developers are indeed dependent on service provider libraries, but this state of affairs isn't a fault of the REST style. Still, to use SOAP in your enterprise behind the firewall, to use the REST style outside on the Web is the obvious conclusion. Good answers to questions, too, including comments about AtomPub and the issue of <a class="reference external" href="http://www.dehora.net/journal/2009/01/09/snowflake-apis/">snowflake APIs</a>.</p>
<section id="comments">
<h2>Comments</h2>
<section id="re-rest-vs-soap-at-esri-devsummit">
<h3>Re: REST vs SOAP at ESRI DevSummit</h3>
<p>Author: Pete</p>
<p>I like how you are trolling a presentation you didn't even bother to watch.</p><p>As you say yourself: "It's impossible to say from the slides".</p><p></p><p>If you had watched the presentation, you would know that he deals with most of your arguments.</p></section>
<section id="re-rest-vs-soap-at-esri-devsummit-1">
<h3>Re: REST vs SOAP at ESRI DevSummit</h3>
<p>Author: Sean</p>
<p>I found it hard to watch. Too much emoting. Not that I'm better (surely not), but it was not to my taste. How did he deal with these arguments? Or at what times? Maybe I could fast-forward to them.</p></section>
</section>REST in realityhttps://sgillies.net/2009/04/02/rest-in-reality.html2009-04-02T00:00:00-06:002009-04-02T00:00:00-06:00Sean Gillies<p>How to RESTfully change the state of power lines and poles? From a thread on the OGC's mass-market-geo <a class="reference external" href="https://lists.opengeospatial.org/mailman/listinfo/mass-market-geo">list</a> (archives available only to subscribers, for shame):</p>
<blockquote>
<p>Actually, I am really talking about poles and wires. Specifically power poles and lines. My example is directly derived from real life. A local electric system has tons of old wood poles that it wants to replace with concrete poles. It is doing this by installing the concrete pole 1m behind the existing pole and then restringing the power lines.</p>
<p>So, the client has a feature type POLES (Oracle table) with all the poles and a feature type LINES (Oracle table) with all the power lines. Not the actual named but you get the idea.</p>
<p>For each pole that is replaced, they update the existing pole record since the new pole will have the same pole id as the pole it replaces but the new pole will be in a slight different position.</p>
<p>Using the current WFS specification, I can make these changes in a single request. I simply POST the following the the URL of the server:</p>
<p><wfs:Transaction>...</p>
</blockquote>
<p>The question of how to do this in a single transaction is a big juicy red herring that has list subscribers rather distracted. The process of disconnecting and taking down wires takes some time, and presumably has to be done before you can take down the pole they connect to. Certainly the new pole can't be erected before the old one is torn down, and only after that happens can new lines be brought in to connect to the new pole. This is not an atomic operation. Bad weather, equipment failure, injury, or any mishap might interrupt the process and leave it an unfinished state for some time. Treating it as atomic in your information system seems more hopeful than realistic, and perhaps even harmful. Once the lines and poles come down, you can't be giving anyone the false impression that they're still up.</p>
<p>Let's say you've modeled your power system RESTfully. You've got pole resources like <a class="reference external" href="http://example.com/power/poles/1">http://example.com/power/poles/1</a>. You've line resources like <a class="reference external" href="http://example.com/power/lines/1">http://example.com/power/lines/1</a> and <a class="reference external" href="http://example.com/power/lines/2">http://example.com/power/lines/2</a>. These resources aren't poles and lines by virtue of the strings in the URI, of course, that's just a convenient design. Lines 1 and 2 connect at pole 1. A utility crew keeps your information system up to date as they work like this:</p>
<ul class="simple">
<li><p>DELETE lines <a class="reference external" href="http://example.com/power/lines/1">http://example.com/power/lines/1</a> and <a class="reference external" href="http://example.com/power/lines/2">http://example.com/power/lines/2</a> as they are physically dismantled.</p></li>
<li><p>DELETE pole <a class="reference external" href="http://example.com/power/poles/1">http://example.com/power/poles/1</a> as it's cut down and dragged away.</p></li>
<li><p>PUT new state (new location, new material attributes, etc) to <a class="reference external" href="http://example.com/power/poles/1">http://example.com/power/poles/1</a> when the new pole is up.</p></li>
<li><p>PUT new state (new lengths, etc) to lines <a class="reference external" href="http://example.com/power/lines/1">http://example.com/power/lines/1</a> and <a class="reference external" href="http://example.com/power/lines/2">http://example.com/power/lines/2</a> after they've been reconnected.</p></li>
</ul>
<p>This isn't finance. Sometimes non-transactional is more honest.</p>
<section id="comments">
<h2>Comments</h2>
<section id="re-rest-in-reality">
<h3>Re: REST in reality</h3>
<p>Author: Gary Sherman</p>
<p>In reality the new poles will all be installed (1 m behind existing), then the lines will be moved all at once.</p></section>
<section id="re-rest-in-reality-1">
<h3>Re: REST in reality</h3>
<p>Author: Sean</p>
<p>I was imaging the lines would be upgraded too. If not, even easier: PUT new state (new location, new material attributes, etc) to <a href="http://example.com/power/poles/1">http://example.com/power/poles/1</a> when the lines are hung on the new pole. Don't change the state of the line at all.</p></section>
<section id="re-rest-in-reality-2">
<h3>Re: REST in reality</h3>
<p>Author: <a class="reference external" href="http://www.jasonbirch.com/nodes/">Jason Birch</a></p>
<p>Keeping the same id feels a bit contrived. Normally, you'd want to retain the old ID in a "removed" state for asset managment reporting on upgrade history, service lifetime, etc, etc. So, in this case, I think you'd PUT the new state (retired) to the old pole, and POST a new pole.</p><p></p><p>Typically a line is connected to many poles, and a pole can have many lines strung on it. Assuming this relationship was modeled by GETing lists of hyperlinks from the following URIs (don't know if this is "correct"):</p><p></p><p>GET <a href="http://example.com/power/poles/1/lines">http://example.com/power/poles/1/lines</a></p><p>GET <a href="http://example.com/power/lines/1/poles">http://example.com/power/lines/1/poles</a></p><p></p><p>How would you move the lines from one pole to another?</p><p></p><p>DELETE <a href="http://example.com/power/poles/1/lines/1">http://example.com/power/poles/1/lines/1</a></p><p>POST <a href="http://example.com/power/poles/2/lines/1">http://example.com/power/poles/2/lines/1</a></p><p></p><p>That seems a bit odd to me, because you wouldn't</p><p></p><p>GET <a href="http://example.com/power/poles/2/lines/1">http://example.com/power/poles/2/lines/1</a></p><p></p><p>Separate "service"?</p><p></p><p>DELETE <a href="http://example.com/power/pole/1/lines">http://example.com/power/pole/1/lines</a> {content: 1,2,5,61}</p><p>POST <a href="http://example.com/power/pole/2/lines">http://example.com/power/pole/2/lines</a> {content: 1,2,5,61}</p></section>
<section id="re-rest-in-reality-3">
<h3>Re: REST in reality</h3>
<p>Author: <a class="reference external" href="http://www.camptocamp.com">Cedric Moullet</a></p>
<p>Jason's use case is quite interesting. I was thinking to another one: usually, when line modification occurs, a mailing is done in order to inform the customers of the outage (typical question: provide me the list of all customers affected by the deletion of this line).</p><p>What would be the correct URI for this kind of question ?</p></section>
<section id="re-rest-in-reality-4">
<h3>Re: REST in reality</h3>
<p>Author: Sean</p>
<p>I'm not sure what you mean by URI for the question. If you designed a system such that the customers for each line (or segment of the power grid? I'm getting out of my depth, here) were enumerated in a resource like <a href="http://example.com/power/lines/1/customers">http://example.com/power/lines/1/customers</a>, you might have a form to which you could POST a message like <a href="http://example.com/power/lines/1/customers/notice">http://example.com/power/lines/1/customers/notice</a> (delivered by email and snail mail).</p></section>
</section>What's the beef?https://sgillies.net/2009/02/04/whats-the-beef.html2009-02-04T00:00:00-07:002009-02-04T00:00:00-07:00Sean Gillies<p>The answer to:</p>
<blockquote>
<p>@sgillies What's the beef with OGC WMS and WFS?</p>
</blockquote>
<p>requires a few more than 140 characters.</p>
<p>First, let me review the good about the OGC service architecture and its W*S specs. The OGC has made interoperability a top priority in GIS. Everybody recognizes this is a huge accomplishment. I do too. My favorite byproduct is the increasing priority of open access. It's no accident. The OGC intended that interoperability would lead to more open access to data, and it has. It's a wonderful thing. My other favorite, and perhaps more accidental, byproduct is that thinking of GIS services as interchangeable commodity components leads rather quickly to considering open source implementations. I also think the OGC has done a fine job identifying and standardizing the parameters of our common processes, and a generally good job on message formats. So much good, I must be in heaven, right?</p>
<p>My beef with W*S is that its architects didn't do their Web homework. Despite the "Web" in the name, service design isn't informed by Web architecture and the understanding of HTTP (the <a class="reference external" href="http://www.w3.org/Protocols/rfc2616/rfc2616.html">Hypertext Transfer Protocol</a>) begins and ends with CGI (the <a class="reference external" href="http://hoohoo.ncsa.uiuc.edu/cgi/">Common Gateway Interface</a>). W*S understands and uses the Web as an alchemist understood and used the elements. We bear the cost of needless reinvention: "Update sequence" instead of HTTP Expiration and Validation, "Web Geolinking Service" instead of standard HTTP interaction, "GeoDDS" instead of Atom. Despite the idea that W*S are designed to be transport-neutral, HTTP is the only significant "distributed computing type" (what the architects call "transport"). The USGS Framework WFS uses no other transport than HTTP. GeoBase uses no other transport than HTTP. Still, our "Web" services remain things that are not really of the Web.</p>
<p>Another minor beef is that in our interoperability fervor we have made standardization holy. The GIS community largely believes that standards should come before implementation, should be built in clean rooms by an elite group of standards scientists, and this stifles innovation. I depend on standards as much as anyone, but I feel we should be standardizing on <a class="reference external" href="http://sgillies.net/blog/872/busting-restful-gis-myths/#comment2037">best practices</a> more than we currently do.</p>
<section id="comments">
<h2>Comments</h2>
<section id="re-what-s-the-beef">
<h3>Re: What's the beef?</h3>
<p>Author: <a class="reference external" href="http://les-ejk.cz">Jachym</a></p>
<p>Further more, I'm missing propper support of SOAP in W*S specifications, which would make OGC "Webservice" to W3C "Webservice" (if I understand this well).This particular thing makes OGC OWS incompatible with Inspire, which is essential for european GISers.</p></section>
<section id="re-what-s-the-beef-1">
<h3>Re: What's the beef?</h3>
<p>Author: Sean</p>
<p>The only thing I'll say about SOAP as a transport, is that it isn't any more of a transport than HTTP is. Look at the mess that is a SOAP DCPType for WxS: WxS (transport independent) over SOAP (not a transport) over HTTP (not a transport) over TCP (ah, there's the actual transport).</p></section>
<section id="re-what-s-the-beef-2">
<h3>Re: What's the beef?</h3>
<p>Author: C. Reed</p>
<p>One minor disagreement - your last statement is incorrect. The vast majority of new OGC candidate standards are "birthed" in the hot bed of implementation and not in a "clean room". These birthing areas could be in the wild or in an OGC test bed. WMS and WFS were birthed around the same time as some other web standards (SOAP, WSDL, etc) but back then no one had even thought of implementing SOAP in 1998 and 1999. So, we are dealing with some legacy here.</p></section>
<section id="re-what-s-the-beef-3">
<h3>Re: What's the beef?</h3>
<p>Author: Sean</p>
<p>Carl (yes?), I agree that there seems to be a positive trend (GeoRSS, KML, GeoPDF), but is it really a sea change in how the OGC makes standards?</p></section>
</section>