OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: Microsoft's Universal Canvas

[ Lists Home | Date Index | Thread Index ]
  • From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
  • To: xml-dev@xml.org
  • Date: Mon, 26 Jun 2000 15:23:54 -0500

The canvas itself should work OK because there is 
enough information there at a low rate of change 
to enable that.  OTOH, when one starts trying to 
configure large mission critical operations around 
this, it may not be possible to run this without 
a lot of human-in-the-loop interventions.  This 
is the classic cascading failure problem (for want 
of a nail).


>From: Ashvil [mailto:ashvil@i3connect.net]

>Another way of looking at this is moving away file management concept
>and into more of a information management problem. We could have
>shared information in Information trees or graphs stored on some
>server in cyberspace (Sounds like the web, will need to resolve those
>pesky 404 errors ;-). We could drag and link the information to create
>the document/view we need. Information sources will have to be more
>well defined and information storage would have to learn to store and
>query semi structured data.

I'd hazard a guess that is where BizTalk framework and the OASIS registries 
are headed.  If you can get really clean schema, that is a good 
start, but my experience is that is tough to do particularly if 
there is any evolution happening in the data at EVERY LEVEL.  This 
was the CALS nightmare.  It looks like a good idea and one thinks 
the data and semantics are stable, but the devil is in the details. 
The military defines things in hideous detail, but there is just 
enough bargaining room and interpretation for any given service 
in the procurement to make these definitions drift on application.

Don't bet the airplane on a character-sensitive system.

This is why I am not holding out a lot of hope for the Semantic Web. 
Things change and local *smart* maintenance is the best solution.  Whatever 
the registry based systems come up with, they have to manage change 
and it is a lot more complicated than some want to believe.  It comes 
down to what you are willing to bet in a process on a data description 
being maintained at a distance from the process with a weakly coupled 
authoritative relationship.  I have more faith in natural allies; keiretsu 
that emerge from discoverable trading based on configured processes 
with validatible results.  After some number of iterations, they learn
enough 
to know what to bet and what never to bet; at that point, it's time 
for the Factory Acceptance Test to see if the performance numbers 
match the Logistics Support Analysis Record numbers.

It all comes down to reliability, maintainability, and testability 
creating a sustainable process and product.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://fly.hiwaay.net/~cbullard/lensongs.ram

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS