[
Lists Home |
Date Index |
Thread Index
]
It is prettier to look at, I agree, and easier to type.
But will it work with the ultimate XML subset? Not
if the IDs aren't there.
An easier to write program language is a good
thing. DOM and SAX and XPath aren't that.
Again, not new news.
<chickenLittleRant>
When does technical elegance become simply less
power, less flexibility, less descriptive scope?
Which of the various application language WGs should
have more primacy for deciding the future of
the XML core itself? Why is SOAP more important
than DOCBOOK? Will the new programming language
structures cope well with all of these diverging
requirements?
</chickenLittleRant>
I know one shouldn't conflate issues, but given
all the threads, trends, and working groups, it
gets harder and harder to rely on the commonality
of XML systems as what is XML and what are the
features of an XML processor become increasingly
dependent on profiles and subsets.
And that is a disaster.
len
From: Jonathan Robie [mailto:jonathan.robie@datadirect-technologies.com]
>He's right that the code examples are real ugly.
>So the alternatives are?
In XQuery, you can remain loosely coupled while improving the figure/noise
ratio of your code. The following computes the PE Ratio for IBM:
let $stock := document("stocks.xml")/stock[@id="IBM"]
return $stock/price / ($stock/revenues - $stock/expenses)
I do think this is more elegant than the equivalent SAX or DOM. It is no
more tightly coupled.
Jonathan
|
