[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 Uche Uche said: Huh? That's exactly what IDL is. IDL is not an exclusive CORBA technology. I think you have the wrong idea. If mapping to "object hierarchies and the object types" were a good way to define an API for XML, then DOM nailed it: IDL is perfect for this. The point is precisely that it is *not* a good way to define an API for XML, so I don't see anything in what you say that would have been better than DOM. Didier replies: Sorry, what is missing here is the context where this message fits in. Previously, I stated the example of the following expression. <account> ...some elements here ..... <balance>20.00$</balance> ...some elements here .... </account> <transaction> .... some elements here ..... <amount>10.00$</amount> ... some elements here .... </transaction> To perform some operations on this serialized format (i.e. xml document) I have the DOM (as an official API supported by W3C). the DOM presents this document as a hierarchy of elements and attributes. However the information encoded is not about elements and attributes that are properties of the syntaxic level but more about transaction and related information like an amount. My problem is to update the account with an amount defined in the transaction. In a programming language I could express this as: Account.balance = account.balance + transaction.amount People knowing the language rules will understand that the account's balance is updated with the transaction's amount. Even non programmer can infer that. Everything else like for instance parsing or using element objects are not relevant to the problem to be resolved. If I have access only to the DOM object I can a) create a program less readable and harder to maintain by processing directly the DOM objects. But the DOM objects do not give me any clue about how the problem is resolved. Give no clues that the balance account is updated with a transaction amount if we are manipulating elements and attributes. (implication XML leads to a more costly solutions - if we take into account the readability and maintenance factor) b) To translate the DOM objects into objects more suited to the problem to be resolved like for instance balance and transaction objects. Thus, in this case I have more code to do to resolve the impedance mismatch between a syntaxic hierarchy of objects and the objects I need to resolve the problem. (again, more cost since I have noise in my program. Extra lines of code to resolve the impedance mismatch created by the DOM). A solution would be to use more brain power and think about how to reduce this impedance mismatch, allowing the developers to work at the proper level. This is what the RPC people are trying to do but this leads to other problems. Instead of reacting like we do (i.e. the xml community) it would be better to fully understand this need and recognize that we have to give extra efforts to reconsolidate the document facet and the document processing facet. This cannot be done by sticking to the syntaxic level, it can be done if we find ways to provide the right tools and the right processing level. If XML documents are an improvement in terms of human readability this shouldn't be done at the detriment of the program's (used to process xml documents) readability and clarity. 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
|