Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] XML Schema: "Best used with the ______ tool"

From: Dennis Sosnoski <dms@--------.--->
To: Michael Kay <mike@--------.--->
Date: 11/28/2008 8:45:00 PM
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

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent