[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: constructive (was RE: Markup perspective not co
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|