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

["Ham, Gary A" <hamg@BATTELLE.ORG>]

Carl,

I am not arguing against you or the need for better standards.  We, in
the DM program are using OGC standards for Web Map services.  We are
also committed to building to the standards of both the EM-TC and NIEM.
And we are not just "compliant."  I.e., using three tags, and claiming
compliance.  We are trying to build real interoperability.  But real
interoperability takes more than a mandate. It takes real acceptance of
that mandate.  And no matter who is running the show, developer
acceptance will be required for real acceptance. It is all a matter of
morale.  Just like in the military, where Generals run the show, but
troop morale and the fit of the equipment to the capability and training
of the troops is a major factor in success.  

Top down mandates can work, but only if they are CLEARLY EXPLAINED and
marketed effectively.  And then, they must actually work as advertised
and not be so complicated that long-term costs are actually increased.
Commercial firms use internal standards because they keep costs down.
They use external standards if they can make more money by doing so. If
the government mandates a standard, one of two conditions are required
before the firm will start implementation:

1. They can bill cost plus. Even if it does not work, they make money.
This is the normal practice of the Federal integrators. For them,
failure is no big problem, since real success in Federal systems usually
about a 50-50 situation anyway (and often that success has less do with
the technology than politics, so technology risk is often ignored). As a
result, there has been a lot of money frittered away (I am thinking
personally of a couple of programs for the Army Reserve, but there are
lots of others. Think of all of the systems that "built" using the DoD
data model.) 

2. They think they can sell more of their packaged software because
standards compliance can expand their marketplace. In this case a
mandate can motivate a vendor into doing standards to maintain or
increase market share or enter new markets, so long as complications
from the standard do not increase costs or competition to the point that
profits are reduced in spite of the mandate.  

So, my mission is to keep the costs of interoperability down in order to
widen the playing field and encourage more and more vendor
participation.  For that reason, anything that appears complicated
scares me a bit.  That said, the world is complicated, and many of our
systems are complicated. So, many of our system-to-system communication
has to be complicated.  But, the more complicated it is, or even appears
to be, the slower true interoperability will happen.  If we do not keep
that fact in mind as we go about our work, we will be far less
successful than we could otherwise be.  I know I sound like a broken
record on this issue. But, since my talents are closer to yours than the
people you actually need to convince, I sincerely think that my "simple
solution first" approach has merit. I am not against complication, I am
just against starting with it.

That said, I have no quarrel GML.  I am going to take a couple of the
GML examples you sent me in the document and work them into content
object in the DE as illustrations of how it can be done. (I already have
a GML point example, but need to do some documentation.)  


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: creed@opengeospatial.org [mailto:creed@opengeospatial.org] 
Sent: Monday, April 03, 2006 10:03 AM
To: Ham, Gary A
Cc: emergency@lists.oasis-open.org
Subject: RE: [emergency] RE: OGC UoM Best Practices guidance

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.ph
>>>p
>>
>>
>> --
>> 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
>
>
>