I'll buy that.  All the tools all the time.  

Although, the engineers aren't choosing.  The contracts 
people do that, then the systems engineers take a 
whack at it, then the logisticians beat on it, 
hand it back to the systems engineers, who 
then say this or nothing, so the loggies cave 
in and pass on the results to the tech writers 
who look at the engineering drawings and find 
mistakes which they then take under-the-table 
back to the systems engineers who issue revisions, 
which the loggies process and pass on to the 
tech writers as new designs, and the tech writers go
ahead and publish the manuals they had ready before 
the loggies came to them but with new drawings. 
Meanwhile, the Work Breakdown Structure is being 
post-fixed by the Contracts people 
so the customer won't discover the incompetence of 
the systems engineers that the tech writers covered up 
so the General Manager could still get credit and the 
company can get the cost-performance award.

OOPS!  The customer has XMLWebSneak! Pro Verion 2.0.
It watches every id on every message and notices 
the hidden ones.  The XMLGrinch strikes!!.

Gotta love these open information systems. 

Is UML generic?  Really?  Or just de rigeur?  
If conceptual modeling is wanted, why UML? 

IDEF had about 14 different models for all of that last 
I looked, all made to interoperate for a complete 
and very detailed description when needed.  That is 
what the KBI guys were dealing with last time 
markup went round this loop.   Will the semantic web 
require 14 different models?  

I'm ok with that.  I am the Grinch.

Len 
http://www.mp3.com/LenBullard

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


-----Original Message-----
From: Rick Jelliffe [mailto:ricko@[...].au]
Sent: Wednesday, February 14, 2001 2:05 PM
To: XML DEV
Subject: Re: Getting The Pizza (Was Processing 'my' XML (was Re: Why
Model Concepts?))


From: Bullard, Claude L (Len) <clbullar@[...].com> 

> Why do we need to model concepts?

Is this just the classic software engineering debate about the value of
closer-to-executable requirements specs?    Which comes down to whether we
capture and analyse requirements using a natural tool (conceptual modeling)
or a generic toolkit (UML) or with implementation tools (e.g. DTDs), which
probably makes the choice a function of the complexity and criticality.

Do we make a conceptual modeling language in which pizza concepts can be
expressed (cold, late, don't-let-boy-with-zits-deliver-pepperoni, etc) and
then transform it? Or do we use a generic toolkit which has generic tools?
Or do we try to shoehorn into the low-level implementation system?  Why not
have all these options available and well supported?