W3C home > Mailing lists > Public > public-xg-eiif@w3.org > February 2008

Re: a "standard" = a defensible instructional precedent [was] RE: EM Standards List

From: C H <craighubleyca@yahoo.com>
Date: Sat, 23 Feb 2008 16:46:41 -0800 (PST)
To: Carl Reed <creed@opengeospatial.org>, public-xg-eiif@w3.org, public-xg-eiif-request@w3.org
Message-ID: <677189.21446.qm@web51402.mail.re2.yahoo.com>

Summary:  EM has more exceptions than standards.  Real
EM systems are designed by people who are pragmatic
and accordingly more concerned about interoperability
and defensible situated design choices than about the
authoritative body that mandated a particular choice. 
Focusing on the latter accordingly is a waste of time.
And EM projects need a good capital asset model
anyway.

--- Carl Reed <creed@opengeospatial.org> wrote:
> However, should this group use cycles to define a
> new taxonomy for "standards"? 

I'd say not.  I wasn't starting that argument, rather
I was avoiding it.  I propose something that already
works to help instrument actual design practice, that
does not establish some predefined hierarchy of de
jure vs. accredited vs. whatever.  I suggest these are
only operational for purposes of assigning liability
(more on that below).

You can wait until the "old" taxonomy based on such
vague non-operational distinction between accredited
and de jure and etc. becomes a problem in real EM, and
then use the categories that I suggest to sidestep it.
 I'm sure the xg-eii archives will still be there.

But I proposed something much more basic than just a
way to characterize standards or standards bodies.  I
think treating EM taxonomy/design decisions more like
real legal and engineering decisions, and assuming
that the detailed defense of designs invokes a wide
variety of rationales, solves many more problems than
just how to prioritize standards and standards bodies.

A capital asset model is the core abstraction of any
asset management system and far more so in emergencies
when decisions must be made faster on less certain
information and more assumptions.  In emergencies,
also, capital assets are often called on to substitute
for each other, and knowing the risks of such changes
is paramount.  EM situations are not about liability
allocation - they're about anticipating problems not
routinely seen & solving them faster with less risk. 
Risk management systems require capital asset models.

Having a single asset model in common for the
standards process, the design process and whatever
user artifacts come out of it seems advisable to me. 
I submit you can't possibly come up with a more clear
or more operational capital asset model than the one I
just proposed.  I am quite sure it can be applied by
persons who speak no English in the field during any
kind of emergency:  Bits are not bodies are not the
agreements/bonds between.  Standards are bits.  Surely
we agree on that.  Why would we use a different model
in the design phase than we would ask users to, in the
field?  And if not, then why in the standards debate?

> Why not just use currently agreed to international
> best practice as to what a standard is and how
> standards bodies are already characterized.

That practice isn't operational, that is, there is no
information useful to an EM system designer nor user
in the practices or categories used to debate de jure
standards.  But they can distract from the actual task
at hand.  Real designers have to make choices whether
to implement or ignore "standards" or to what degree,
and I think we would agree that EM in particular puts
more pressure on those designers to be pragmatic.  

What is "best practice" to a bureaucrat is not to the
user or designer.  The practices you refer to help to
define relationships between the standards bodies
which is useful for routine work.  But is that a
practical position for EM?  Does anyone really care
whether a standards body is involved, or have need to
characterize the standards bodies at all?  Microsoft,
for instance, sets a lot of de facto standards without
a lot of help from those bodies.  But even the use of
the term "de facto standard" is problematic as it gets
us into a pointless argument.  I think we would agree
that if interoperability with some existing Microsoft
databases is required by an EM system, that is enough
of a rationale to make such a choice defensible even
in the total absence of any standard from any body.  I
think EM as a field has more exceptions than routines.

Accordingly I prefer to ignore inter-agency issues and
treat all design precedents as equal, so as to focus
on the design process and actual defense of situated
choices.  In this sense an EM standards audit would be
more like real legal arguments than like a rigid test
suite.  I suggest we don't need to characterize the
"provenance" or credibility of any body or standard. 
Instead we just make note of the fact that some choice
may be "defensible" because it's from the UN, or the
IEEE, or the W3, or from the dominant vendor, or in
use among particular players, or is open source, or
whatever other reason.  I see no way to characterize
that defense with a hierarchy of standard bodies, and
absolutely no reason to waste cycles on the difference
between accredited, voluntary, de facto,
vendor-defined and government-defined precedent. 
These are just different ways to allocate liability. 
Focusing on that too early may cause more failure than
a focus on interoperability.  It's far too easy just
to say "we did it because the standard said to do it"
without reference to the constraints of the actual
problem...

I see no reason to comment on this further however.  I
will happily revisit this in a couple of years and am
quite sure I'll find many examples of failures caused
by copying best practices of bureaucrats into EM work.

Craig Hubley



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Received on Sunday, 24 February 2008 00:46:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 7 October 2008 02:05:09 GMT