[OSGeo-Discuss] Re: [OSGeo-Standards] TMS and WMTS

[Brian Russo]

On Fri, Apr 9, 2010 at 7:48 AM,  <creed at opengeospatial.org> wrote:
> 3. Complexity. This is a major topic of discussion in the OGC Architecture
> Board and other OGC forums. Allan is correct, there is no concerted effort
> to makes things complex. However, when there are a myriad of requirements
> from multiple domains for functionality in a given interface, apparant
> complexity can be the perceived result. Take describing a sensor. Very
> easy to define an encoding standard that states that a sensor has a
> lat/long location, measures temperature, and stream temperature in degrees
> centigrade. But wait, how about a measure of uncertainty, time of last
> maintenance, error tolerances, time of observation, and so forth. Suddenly
> what started as simple is not so simple any more. And this gets even more
> interesting when the sensor is part of an emergency alerting system where
> lives are at stake.


Yeah we call it mission creep. If your standard ends up too complex
then it means
your original scope was too large. You should revisit your scope and
constrain it.

Ask the hard q

A core-extension framework helps to some extent, but it depends on
what you're modelling.
If your 'extensions' will be adding very dissimilar data types then
your core may end up being
overly complex anyway and not very lightweight. So while that sounds
good, it depends on
the specific implementation, it could actually end up being worse than
a holistic approach.

>
> That said, the OGC Members have approved and are moving toward
> implementing a policy called "core-extension" for OGC standards. The
> concept is very similar to a UNIX kernel and extensions/commands related
> to the kernel. The idea is that the core is as light-weight, as simple,
> and as easy to implement as possible. The first OGC standard that has
> fully moved to this model is Web Coverage Service, which is out for public
> comment right now. Others are in progress.

Is it really out to the public? Not to be snarky, but who is
considered the 'public' for these things?
The stakeholders too busy doing actual work are the ones you want to
engage with.

>
> We welcome and encourage comments from the OSGeo community!
>
> 4. Contrast that with the FOSS approach of debate on a mailing list . . .
> Well, no OGC standard goes through the process without considerable debate
> (which someone else mentioned can be frustrating due to the knowledgeable
> input). Under the current OGC process, any standards development work
> requires a team effort. For example, 3 or more members are required to
> start work on any standard. As an example, there is a new standards
> working group in the OGC for PUCK (a sensor API for ocean observing
> systems). There are 6 charter OGC Members (representing government,
> commercial, research, and universities) who proposed the work and an
> additional dozen OGC members participating. They have regular conference
> calls and email debate. They must brief the entire TC on their work. The
> OGC Architecture Board will review and provide guidance. The document will
> be released for a 30 day public comment period followed by more discussion
> and debate. The PUCK team will then need to brief the OGC Technical
> Committee at a F2F meeting prior to approval for an electronic vote for
> adoption.

I have no doubt there are many people smarter than me working on these
standards.
The issue isn't whether there's a substantial process - it's whether
the right people
are involved. For example having a couple people representing government sounds
great but.. I mean if you're talking Federal & State then you're
talking organisations
larger than some countries. Which part of the government are you talking to?
How do you know it's the correct one? I know you don't control a lot of that.
Still, it matters.


> Which gets back to a point Allan made about the number of OGC folks who
> understand a standard. Only fifteen or twenty individuals in the OGC will
> really understand PUCK. But in standards work, there has to be a level of
> trust - trust that the individuals working on a given standard know what
> they are doing and creating a strong, useful standard. This trust is
> identical to working on an open source project - you have trust in your
> fellow collaborators. If there is not trust, then in OGC work the standard
> may not progress into a vote.

It's not just about internal trust - there has to be external trust as well.
Again, the customer is external not internal. A history of
unsuccessful standards
does not promote an attitude that.. 'hey this is an organisation I
should follow'.

-- 
Brian Russo / (808) 271 4166