[
Lists Home |
Date Index |
Thread Index
]
A shared model is certainly desirable. Is XML accepted
again, only because 'it is there' or 'there is no better
alternative'?
At one point, Neil A. Kipp proposed a simpler syntax that
could do the job of XML. RelaxNG has a simpler syntax.
So that is a possible improvement, but again, YetAnotherOne.
Defending XML used to be one of the principal topics of this
list. It is seldom necessary these days which is why it is
a reasonable time to start questioning assumptions... or safe.
Do messages have long lifecycle requirements? Is transparency
an effect of the model, the syntax, or just the shared view?
When we say 'messaging' and 'XML' in the same breath as if
they were inseparable, the innovation bell rings. Again,
timeliness is everything but some games must be played a
long ways ahead. Even XML would not be there had some
brave souls not stepped away from CORBA, etc., and taken a
second look at a 'failed document format standard', and the
only reason it was accepted readily is that an even cruder
form had 'succeeded wildly'.
len
From: Christian Nentwich [mailto:christian@systemwire.com]
Len,
are you suggesting that we go back to CORBA? xml-dev feels like
chewing gum sometimes.
We like XML on the wire because we can read it and because, provided
you use XML Schema well and put effort into modelling, you see a
representation of your business model on the wire.
It's unfashionable here to defend XML and XML Schema... but I will.
Business analysts who look at a UML representation, coders who
translate the XSLT stuff, testers who pull messages off the wire,
support staff who pull messages off the exception queue, all see
a shared model. When they say "the adjusted date is wrong" they all
understand each other, and can talk to each other without hours of
reverse engineering and analysis.
I deal in EAI and I'll have XML for messaging any day, thanks. As for
the universities.. most of them don't see it as their job to come up
with Yet Another Infrastructure Standard. They are looking at next
generation mobile middleware and other hard problems.
A simpler XML would of course be appreciated... with the usual
requests around entities, namespaces and processing instructions.
|
