[
Lists Home |
Date Index |
Thread Index
]
From: Paul Brown [mailto:prb@fivesight.com]
> [Claude Bullard]
> It's tough to tell designers that XML only really cares
> about well-formedness and then get them to buy into a
> system based on validity. It's like giving them free
> popsicles without sticks.
>Or, put another way, XML only solves the problem of inlining metadata,
>not providing semantic and structural consistency to that metadata.
Structural consistency it can support. Semantic consistency is hard
for any syntax-only system. That is for object modelers: pick
one and stick with it. As they said, it took EDI some decades
to get more than a few supporters. On the other hand, that means there
are now more than a few semantics to be pillaged by the XML business
modelers. No doubt they are.
>Most people meet semantic and structural incompatibility in XML documents
>only later in their life as XML users, which is unfortunate, and it's
>hard for people to imagine the difference between XML representations of
>a single tangible, concrete object in the real world. Incompatibilities
>in representation and semantics are also where cost (for disputes, for
>integration, etc.) enter the picture, making it doubly unfortunate.
>(Because it spawns things like:
>http://www.optimizemag.com/mckinsey/2003/0721.html)
The chicken and the egg problem of adoption and tools support is a
known. It is also how software engineers make money selling new tools
to improve old ideas and processes. That's the biz.
OTOHJ, the article says "the installation of XML calls for process
reengineering"
It doesn't have to. Some people make that happen as they do because
they can and know they should. People moving to XML are probably sitting
on processes and software that are long in the tooth, so the CIO decides
to pick up all the jacks with one toss of the ball. That is a lifecycle
problem, not an XML problem. However, ten years from now when it is
time to molt the skin of these processes, I'd rather be in a position
to do it with data and operations over markup than without it.
IME, XML and schemas are there for clarification of intent about
names and structures, and then deciding if that is to be used for automation
or just
as a means of documentation. But they can't solve completely
the issues of definitional scale: local systems of definition vs. global
systems of definition. They can't even completely isolate them.
For that, one needs something like RDF, and then one still has
to deal with the politics of adoption, and the reality that
meaning drifts in any open system of communication. That is
why the registry does operate best at the atomic level just
as software likes encapsulation. Old news but we are software
geeks. It is the commercial where the kid after attempting
to tell them details he finds relevant finally just says,
"we're saving 5 cents a transaction". It would interesting
to see where he gets those savings.
I'm not building for the masses. After CALS, I found
the crusades to build application languages that "Everyone
must adopt or die" to be ego exercises that while not fruitless,
are some boring. One waits a long time to get the cookie.
Application languages that do something interesting for anyone who
downloads a handler and can get reasonable editing support, aren't boring.
I like bits like X3D. It works now but the range of applications
is unknown. That makes for great adventure: a sound ship, a good
crew, a fuzzy map, some possible monsters, and some beauties to
be convinced to sign on. That is great fun. If one wants to
conquer the world, raise an army. If one wants to pillage and
party, raise a crew. Yo ho ho and all that.
>One approach that looks interesting is the UDEF:
> http://www.udef.org
>Which at least attempts to provide some equivalence between ns1:tomato
>and ns2:tomatoe...
I'm not one with a lot of faith in efforts that have the word 'universal'
in them. Boltzman entropy is software chiggers. I appreciate any effort to
cross-index. It saves me some time finding the right thing to steal
and extend. ;-) Evil geniuses for a better tomorrow, always.
len
|
