[
Lists Home |
Date Index |
Thread Index
]
Hi Simon,
Simon said:
And that's _all_ that XML should solve. Piling the other 80% of the
work
into XML is precisely what brought us to the unspeakable mess we have
today, whoever's incredible fault it may be.
Didier replies:
This is a point of view. A second one would be to say that if we get
that mess is because there is:
a) A lack of reasonable solutions for the problem to be solved
b) a lack of tools. The actual tools are too low level and necessitate
more work than a classical way of doing things. Progress and
productivity is not more work, it should be less work.
c) We are not really listening to the needs of the developers and the
constraints they are facing.
If, for example, a tool where to be added to some dynamic binding
languages like ECMAscript or Java and that an XML document where to be
presented as a hierarchy of object, not the syntaxic ones but the
objects represented by the elements, we would probably have more buyers
of this solution and probably less Microsoft stuff. Actually, to perform
the following operation:
Account.balance = account.balance + transaction.amount a developer would
have to parse the XML document then move the values in variables, etc. A
lot of stuff not useful to the the problem to be resolve and a counter
productive practice. This is more than they have to do today. So why do
we expect that they will follow such path? Do we take the longest route
ourselves? If yes we are maybe a community of strange beings :-) if no,
why do we ask the others to do so? However, if instead of that type of
solution we where to propose that XML documents are transformed into an
infoset and that this info set can be accessible both a the syntaxic
level and the semantic level, they would buy that. The gain is that
instead of having an RPC we would have a significant document.
I think that what Jon Bosak is doing right now is a good way to improve
the situation if that is not too late. Defining business transactions as
XML document is a good thing. Instead of having a SOAP call I may get an
invoice encoded as an XML document. The latter is potentially richer
than the former in terms of information. Now, if this invoice can be
processed easily with tools that do not ask the developers to go back in
time, this may take off. All my wishes to Jon efforts.
You know its easy to say, they are wrong when in fact we (and mostly the
W3 organization) created the situation. Its probably time to take some
responsibility of the consequences of the XML community actions and ways
of thinking. I know its not popular to say that :-)
Cheers
Didier PH Martin
|
