RE: [xml-dev] Creating a single XML vocabulary that is appropriately cus

[Len Bullard <len.bullard@uai.com>]

Hi Roger:

This is too long.  No time to go short.  Apologies.

The business case is that one has to determine what is being required and
not attempt to build a one size fits all or a 'this can live for two
centuries' schema unless that IS the job.  The jobs rots in the terms:
appropriate for a community.  Too often they are communal in name only.   A
fellow on Scoble's blog had a wonderful description in which he said
sometimes we really should get outside and quit listening only to our own
echo chamber (A-listers may not really matter).

The time and effort spent reconciling some n number of different systems is
mostly spent communicating and negotiating.  The problem of web industries
originates in the standards game where it becomes a competitive advantage to
be the owner of the language.  Web designers too often start with the 'first
we form a committee to achieve consensus across the industry' instead of
concentrating on building a product that happens to support XML in and XML
out.   This can paralyze the development team and delay the time to market
of an otherwise simpler product.  Sometimes it is better to build that core
product first and compete with it in the market.   

We too often think that the rationality of the design reflects something in
the real world.   In meatspace, you can have five instances of what you
rationally believe are the same type of transaction only to discover each
agency has local quirks that they will not or cannot give up.  The question
is is it cost-effective in the market to try to build for these or is it
better to tell the customer to scrap the quirks and force the cost of
evolution back into their hands?

I suspect that systems such as the medical records systems are rife with
this.  We know it is there in the public safety systems.   Too many problems
are proposed to be solved in single systems or procurements.  An RFP with
too many moving parts with squishy insides appears (single citations of
giant efforts that turn out on inspection to be incomplete or unimplemented
and in some cases unimplementable).   The vendor signs up, the citations are
in the contract, then the vendors ride the tiger.  At the conclusion (when
the money runs out), what is delivered is Rube Goldberg.

I understand that the flip side is lots of little systems that don't
communicate perfectly, but my experience is the friction of lots of little
systems can be smoothed easier over time locally than trying to smooth it
out all globally at once because like smoothing lumps in your bed, push on
one and another pops up because a new requirement was discovered or
introduced.  It is classic whackamole.  To get around this, it can be better
to consider the arabesque as a lot of little segments and deal with each
separately.  That is why messaging system dominate document systems on the
web although it isn't the case for the humans.  Humans adapt nicely to
conditional documents but try to build a fully role/agency system for
multiple agencies under multiple umbrellas, eg health, public safety,
transportation, etc. as the Department of Homeland Security does seeking
100% coverage and full up automation with air tight traceability.

Eventually someone explains to you the dispatcher picks up the phone and
calls the dispatcher in the next county.  Fully automated intelligent
dispatch is a gremlin.

Designing for evolution doesn't mean evolving the system to its end state
before its birthday.  It means it works for the requirement at hand and can
be adjusted.  If that means clean up, it's a better option than expensive
delays and no delivery.  You are asking where to set the customization
features.   There is no single good answer.  There are techniques (eg,
Schematron, wild cards, renaming, etc.,).  But as for 'appropriateness',
YMMV.   One size fits all is an attractive form but a bad fit and an
endlessly complicated function.

len


From: Costello, Roger L. [mailto:costello@mitre.org] 

Steve Newcomb wrote:

> In retrospect, it seems possible that the W3C's
> focus on machine-to-machine  communication and 
> AI left little room for questions about human 
> issues, like the issue of how to deal with the 
> fact that top-down authority over document types 
> simply can't work across diverse human communities. 
> This story is very far from being over.


And Len Bullard wrote:

> Given my druthers, I'd rather maintain multiple 
> schemas over trying to convince multiple groups 
> with different semantics in the same community 
> that they should converge.  The mammal problems 
> are the most expensive.


"top-down authority over document types simply can't 
 work across diverse human communities"

"The mammal [human] problems are the most expensive"


These are very thought-provoking comments.  

I would be appreciative if you - Steve and 
Len (or anyone) - would elaborate upon these comments.  
I am eager to have my eyes opened to new ways of
thinking and dealing with information.

/Roger 

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.