[OSGeo-Standards] [OAB] [RESTful-Policy.SWG] Encodings and REST - New conversation on standards organizations

[Martin Daly]

Carl,

> So, following up on the last point, I believe that OSGeo can request the OGC
> share an in-progress candidate standard for OSGeo internal
> review/comment/experimentation. This would require a formal request to
> me as OGC Technical Committee Chair and then formal approval by the SWG
> voting members. Of course, the OSGeo community, as per the OGC-OSGeo
> MoU would need to respect the OGC IPR policy terms and conditions. And of
> course the SWG could vote no if they felt that the candidate standard too
> immature to share.
> 
> Comments welcome! And of course, communication can always improve!

More openness is great, so please press on. However it is, in this case, a complete and utter red herring. IGNORE THE MAN BEHIND THE CURTAIN!

The opposition to the proposed standard is not at all about the openness of the process. Instead, all of the criticism - at least, that I have seen - is entirely on the substance and nature of the proposal.

Setting aside whether or not the intentions of the submitting organisations are entirely altruistic; *and* setting aside whether or not the proposed standard is in-and-of-itself well enough written to be implementable; *and* setting aside whether or not there is too much overlap with existing OGC standards; *and* setting aside whether or not the proposed standard deserves to bear the moniker "REST"; the fact remains that the proposed standard simply presents the public face of the private data structures and functionality of a single piece of software (and why shouldn't it - that is precisely what it was designed to do).

As such *all* other implementations must either map their capabilities to the proposed standard, or add capabilities to match the proposed standard. Whichever is necessary, the original implementation will short-to-medium term at the *very* least remain the gold standard.

This is not even about the submitting organisations, nor even the precise content of the proposed standard. Exactly the same arguments would hold true were we looking at UMN MapServer "map" files as a proposed OGC standard, for example. (Now I've gone and planted a crazy idea in a few heads...) The same arguments also applied over KML.

As long as the SWG can - legitimately, by the rules - cite "backwards compatibility" as a reason to reject comments made in the RFC period, as is rumoured, then everyone else just has to take the proposed standard more or less as-is.

This is not a recipe for a happy broader (software implementing) OGC membership nor, as everyone here can see, a happy broader (software implementing) OGC community.

Martin

********************************************************************************************************************
Cadcorp is a trading name of Computer Aided Development Corporation Limited; registered in England;
number: 1955756. Registered office : Sterling Court, Norton Road, Stevenage, Herts SG1 2JY

This email is confidential and may be privileged and should not be used, read
or copied by anyone who is not the original intended recipient. If you have
received this email in error please inform the sender and delete it from
your mailbox or any other storage mechanism. Unless specifically stated,
nothing in this email constitutes an offer by Cadcorp and Cadcorp does not
warrant that any information contained in this email is accurate.
Cadcorp cannot accept liability for any statements made which are clearly the
sender's own and not expressly made on behalf of Cadcorp or one of its agents.
Please rely on your own virus check. No responsibility is taken by Cadcorp
for any damage arising out of any bug or virus infection.
********************************************************************************************************************