[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Schema: "Best used with the ______ tool"
Michael Kay wrote: > I don't have any performance data, and I would love to see some. But XSLT > and XQuery processors also use tree representations that are much faster and > smaller than a DOM (in one recent Saxon measurement, 40% of the size, 40% > faster to build, and 30 times faster to navigate), and I don't think there's > any intrinsic reason why they should be slower than data binding. I'm not > saying they are faster, just challenging your assertion that they are > impossibly slow - I think the burden of proof is on you. > I don't think I said they were "impossibly slow", though I would be surprised if XSLT and XQuery performance could actually match data binding for reasonable business applications. If you'd like to try a comparison, I have an earthquake data set and schema I use for comparing web service stack performance. The client queries the server for quakes within specified time, location, and magnitude ranges. The server responds with all the matching quakes, grouped by geographical area (using predetermined standard areas) and sorted within each area by date/time. I'd love to see this implemented using XSLT or XQuery by someone who knows what they're doing, to see how the performance compared with the data binding implementations. >> XQuery may be usable when you only need a few selected items >> of data from the documents, but it's not a realistic approach >> when all the data in the document is actually used by the application. >> > > Why? > Why would any developer in his right mind want to first do queries to retrieve the data from the document and then organize the data himself into something usable by the application? I see that Boris has responded to this separately, and agree with his points. >> For most web services applications the Java (or other programming >> language) representation is actually primary, and XML is just >> being used for interchange. >> > > I don't think it matters which is primary, the complexity comes from having > two representations and keeping them aligned. But I would have thought the > format used for data interchange is primary in the sense that it needs to be > agreed with other parties, whereas the Java representation is under local > control. (Unless of course you're running the same code at both ends, in > which case I'm not sure why you're using XML at all.) > There's a surprising amount of web services work that's being done where there's only one client and one server implementation, especially when the service is being initially developed and the formats are subject to a lot of changes. But I do agree on the problems involved in maintaining two representations. How much of a problem this presents for data binding when the schema changes depends on what you're doing to the schema. If you're just adding new optional data and perhaps changing some names, it should be trivial to regenerate the data binding model and adjust your application code to match (especially using any modern IDE). If you're making structural changes to the schema the changes in the generated model will require more work on your application code - but the same is going to be true when using XSLT/XQuery. - Dennis
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
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
|