RE: [xml-dev] XML Drilldown...

["Len Bullard" <cbullard@hiwaay.net>]

Sorry it took a while to get back to this topic.  I've been busy building
and releasing a new VRML world and it had a lot of code and the usual
release challenges.  Anywho... a long reply...

Yes, David, drilldown through systems information acquired from multiple
contractors if a big challenge.  XML can be part of meeting it but the
acquisition challenge is only partly technical.    Remember that a parts
list is only a piece of a technical manual.  There are scads of information
types required to support a system.  The lifecycle time required to get a
new technical manual into the field is almost as long as the system it
supports and because information technology evolves at a rate much faster
than the systems it is applied to, it is often the case that the support
systems are constrained to evolve at a much slower rate than the commercial
technologies they are hosted on.

The US Army, contractors and the US Marines are still using the IADS browser
that we developed for them waaaay back before there was an XML or even a
World Wide Web.   Given all the development done in the intervening years,
one would think that the services would have moved on to newer technologies.
Instead, they continue to rehost and improve IADS.  Why?  They control and
own the product.  That has the benefits of controlling the source (no
spyware), keeping it stable (no release issues beyond their own walls) and
no licensing costs.  While one might make the case that it would be cheaper
to develop over web technology, it wouldn't have the advantages of control
and stability.  

Using contractor-provided IETMs means taking on the licensing costs for any
software the contractor develops and turns into a profit-center or having to
become the shill for that contractor and forcing other contractors to use
that one.  If they have to do that, they might as well own their own system.
We once went to another division of our own company suggesting that they use
the IADS browser.  They decided to go with their own software.  Eventually,
they lost the weapon system support contract for that and other reasons.
When we were Unisys, we tried to get them to support the commercial version
which had XML and stylesheet features years before the web had them.  They
decided to go to Microsoft and use HTML.  Once again, that failed to make a
dent in the IETM market.  Marketing wonks don't always understand that
markets don't bend to their spin in the face of the hardboiled problems of
large integrated acquisitions.

So in some parts of the military, they use IADS and require the contractors
to develop information for it.  This means keeping to the content standards
without fail and that means contracts for organizations that vette and
assemble the various sources of radio parts lists, engine parts lists, etc.,
and all of the technical instructions for using each piece, each assembly,
each system, etc.  Given that there can be various kinds of information from
remove and replace to training to diagnostics and so on, you can conclude
that this is one expensive manual by the time it gets to the customers.

So while it is perfectly reasonable to build a more advanced IETM that
enables the use of more powerful presentation and navigation techniques,
that advance comes at a high cost.  It affects not just one company or
government organization, it affects thousands of them.  If they decide for
example, to use real-time 3D, they have to use a real standard, not Google,
not Microsoft, not SGI, not Skyview, not Intergraph, etc.  Otherwise, this
won't ever make it through the procurement process.

So, David, it does come down to the politics and money as Andrew said.  This
isn't a banal or evil problem; it is the most basic problem of logistics
supply chains that gave rise to CALS that gave rise to more of the web than
some care to admit or understand.  It is the problem of computer-aided
acquisition and logistics, the original meaning of CALS.  

This wheel turns slow and grinds small.  I'd love to help build such a
thing, but I've worked on one before and they are still using fifteen years
later.  Is it time to do it again?  I think so but then I know a lot more
about hypermedia, 3D and network technologies than the last time.  What we
were only dreaming about on the US Navy MID committee is now commercially
available and in most cases, can be built over open source, but building it
is just the very beginning of such a project.  Like any other materiel, it
has to be costed, procured, serviced and outfitted.   Technical authors and
illustrators have to be trained to author for it.  Regulations and
validation procedures have to be created.  Supply chains have to be set up.

And on and on.  That is why military systems cost what they do.  It isn't
corruption; it is planning, coordination and logistics.

The rest of it is about money and politics.  No free lunch.

len


From: david.lyon@preisshare.net [mailto:david.lyon@preisshare.net] 

Quoting Len Bullard <cbullard@hiwaay.net>:

> ..

Hi Len,

It finally occurred to me what you might have been talking about the  
other day with xml drilldown problems. It came to me in one of those  
moments when I was doing something completely unrelated.

Were you implying that in the military there is a problem with product  
drilldown? for example; an armoured car has a problem. But it is the  
radio. The vehicle is made by Chrysler.. but the problem is with the  
radio.. made by say Shiwatsu..

The parts-lookup program drilldown only goes to the radio unit. Then  
you need a completely different program to get the diagrams for the  
radio.

Then, after finding the part number. There are five different parts  
suppliers that are able to supply the same part at different prices.

Actually, this is the classic modern industrial parts dillemma. Too  
many items from too many suppliers.

But wasn't xml going to solve all that..? :-) One would think that it
could...

Regards

David