RE: [emergency] RE: OGC UoM Best Practices guidance

[creed@opengeospatial.org]

Gary -

Perhaps a bit off topic, but I hear the developers pain. That said, who is
running the show - the developers or the managers/policy makers? Perhaps
the issue you are pointing to is more one of culture than not wanting to
take the time to learn something new and correct. I managed a development
staff (young, old, geeks, gurus, strange personalities) for many years. I
gave them considerable freedom to be creative and be productive. BUT, and
I mean BUT, their performance reviews included how well they adhered to
very specific documentation and coding best practices, proper testing of
the code they developed, adherence and use of a significant set of
standard interfaces for our product line, and so forth.

Can you imagine if Oracle or ESRI or Microsoft or any other software
provider did not require their programmers/developers/engineers to use
their companies internal software development standards, including all
existing APIs, interfaces, standards, etc? There would be chaos.

This issue is even more on the front burner with SOA gathering so much
steam. SOA mandates the use of standards. SOA typically forces cultural
changes in the enterprise - like developers and managers working more
closely together to understand, define, and document business process.

Sorry for the slight rant, but at the end of the day, implementation of
standards is driven from the top down and the bottom up. Uptake is a
function of both policy (top down) and getting the job done (bottom up).

I would hazzard a guess that if corporate policy stating that a given
standard will be used is coupled with resources that made it easier for a
developer to implement, then uptake would not be an issue.

Cheers

Carl


> Carl,
>
> At least you provided examples!!!
>
> All kidding aside, it is not me that I am worried about here. It is a
> group that I tend to identify with, the journeyman software developer.
> Only with their support is adoption by a significant, traction capable,
> number of real vendors and government programs possible.  Mandated or
> not, developers only build what they think is reasonable. (Think Ada,
> which was a superior language but essentially failed, in spite of
> government mandate.) So you will have to convince those who actually
> build software that what you are asking them to do is reasonable for
> their cost structure and schedule.  I am in no way arguing correctness.
> You are correct, or at least more so than I am. I am pointing out that
> "correctness" can sometimes be so impractical that it leads to failure.
> So, if you want correctness to succeed, it has to both be reasonably
> easy to implement AND appear so to the journeyman developer.  So, enough
> "theoretical correctness."  We journeymen need to be provided with hard,
> real examples that meet specific functional problems.  Otherwise,
> prepare for irrelevance.  Standards geeks like Gary Ham and Carl Reed
> will just be ignored, and developers will go on building non-standard
> stuff that just "works."
>
> The good thing about the contents you provided is that there is an
> example for each of the schemas provided in the document.  The bad thing
> is that there are so many choices.  The chance that a development
> project will cover the gamut of the choices decreases exponentially with
> each extra choice provided. The only way to get around that would be to
> build some kind of very complicated "information hiding" software to
> make implementation of the choices easier.  It is going to be
> interesting.
>
> Respectfully,
>
> Gary A. Ham
> Senior Research Scientist
> Battelle Memorial Institute
> 540-288-5611 (office)
> 703-869-6241 (cell)
> "You would be surprised what you can accomplish when you do not care who
> gets the credit." - Harry S. Truman
>
> -----Original Message-----
> From: Carl Reed OGC Account [mailto:creed@opengeospatial.org]
> Sent: Sunday, April 02, 2006 11:00 AM
> To: emergency@lists.oasis-open.org; Rex Brooks
> Subject: Re: [emergency] RE: OGC UoM Best Practices guidance
>
> Gary and Rex -
>
> Fully understand. The OGC UoM and related Observations and Measurements
> work have been designed to insure that ALL metadata for a given
> measurement (say from a sensor) can be accurately captured, encoded, and
> communicated. The OGC members have determined that for our standards
> work related to sensors etc that we must insure that the accuracy of
> measurement semantics, measurement precision, and measurement accuracy
> and so forth must be accommodated. This does not mean that an
> application needs to use all of the capabilities - just that that they
> must be there if needed. Much of this decision has to do with the level
> of ambiguity that an application can live with. This is why UoM is
> important.
>
> Anyway, attached is the latest OGC Observations and Measurement
> document.
> The members approved release of this Discussion Paper last month. Has
> not yet been posted to the OGC web site but will be soon.
>
> There are numerous examples showing how UoM can be expressed as part of
> a larger sensor observation encoding payload. Also shows use of GML, O&M
> and UoM used in concert.
>
> Not sure if this will make Gary's life any easier :-)
>
> Cheers
>
> Carl
>
> ----- Original Message -----
> From: "Rex Brooks" <rexb@starbourne.com>
> To: "Carl Reed OGC Account" <creed@opengeospatial.org>;
> <emergency@lists.oasis-open.org>
> Sent: Wednesday, March 29, 2006 9:32 AM
> Subject: [emergency] RE: OGC UoM Best Practices guidance
>
>
>> At the risk of catching a ration of flame from most all sides involved
>
>> with this discussion, I tend to favor two ways of dealing with units
>> of
>> measure:
>>
>> 1. Specify that uom be specified either in the specification or that
>> each implementation must specify what uom it uses, mandatory--and in
>> web services, you just don't partner with companies whose uom in their
>
>> wsdl does not match up with yours; 2. Specify metric system, period.
>>
>> Both are aimed at letting the marketplace enforce the standard, but
>> Darwinism has a bad name in these parts, since it inevitablly means
>> letting chips fall where they may, and in these parts chips are people
>
>> so both of these are non-starters.
>>
>> In the choice arena between the concerns of programming realities on
>> the ground versus getting critical information correct in critical
>> moments, I tend to fall on the side of insisting on putting the burden
>
>> on the quality assurance cycles in software development and test the
>> bleep out of every last thing and just keep testing till it works 95%
>> of the time. (Reality says 80% flies, but in this case, I have to
>> remind folks that in these parts chips are people.)
>>
>> Ciao,
>> Rex
>>
>> At 10:42 AM -0700 3/28/06, Carl Reed OGC Account wrote:
>>>As I mentioned.
>>>
>>>
>>>Carl Reed, PhD
>>>CTO and Executive Director Specification Program OGC
>>>
>>>The OGC: Helping the World to Communicate Geographically
>>>
>>>---------------------
>>>
>>>This communication, including attachments, is for the exclusive use of
>
>>>addressee and may contain proprietary, confidential or privileged
>>>information. If you are not the intended recipient, any use, copying,
>>>disclosure, dissemination or distribution is strictly prohibited. If
>>>you are not the intended recipient, please notify the sender
>>>immediately by return email and delete this communication and destroy
> all copies.
>>>
>>>"The important thing is not to stop questioning." -- Albert Einstein
>>>
>>>
>>>Attachment converted: Macintosh HD:Units_of_Measure_Rec#10783E.pdf
>>>(PDF
>>>/<IC>) (0010783E)
>>>---------------------------------------------------------------------
>>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>>generates this mail.  You may a link to this group and all your TCs in
>
>>>OASIS
>>>at:
>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>> --
>> Rex Brooks
>> President, CEO
>> Starbourne Communications Design
>> GeoAddress: 1361-A Addison
>> Berkeley, CA 94702
>> Tel: 510-849-2309
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>