[
Lists Home |
Date Index |
Thread Index
]
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
|
