[
Lists Home |
Date Index |
Thread Index
]
On Wednesday 05 March 2003 10:02 am, Bullard, Claude L (Len) wrote:
> And you are right, lots of systems, most in fact,
> worked without the ESIS. But the interoperability
> of the systems was poor in the extreme with the
> exception of the operation of exchanging SGML
> and even then, one needed expert knowledge to
> achieve that seamlessly.
Well, one attempt at that was XML, which in many ways just codified existing
practice.
From a practical perspective, it was generally not the *instances* that caused
the interoperability issues, so much as things like entity resolution, or
formatting mechanisms. Some of those things are still biting us in the
backside.
> 1. Costs usually come down over time if the
> manufacturing volume is reasonably high.
>
> 2. Systems can be tuned within reasonable
> limits to missions without too much custom
> coding by mixing an matching parts.
Yes. Where the cost/benefit ratio is reasonable, it's perfectly valid to have
a common set of components.
> I don't dispute the value of custom coding;
> just saying it isn't needed for the majority
> of the work we do.
I disagree. I think that all we *ever* do is custom coding, and that all the
common tools really do is make our life a easier. I would argue that in some
cases, even this is not true.
> As I said to David, the world of SGML was big systems
> and specialists using publishing systems and not networks.
Perhaps so. My experience has been right across the board.
> As a result, if XML is to be a core technology,
> it has to be very resilient and reliable in the
> face of not-quite-ADEPT hands.
The *tools* have to be, not XML itself. At the end of the day, the syntax is
largely irrelevant to most people but the tools and applications are not.
XML wins because you can bring a large number of tools and interpretations to
bear upon it.
|
