Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@d...] >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
|
