The Peace Process: DOM and namespaces...

["Rick Ross" <rick@xxxxxxxxxxxxx>]

Dear XML/XSL Community,

I need your ear, and I sincerely do not want to cause trouble.

We are in a conundrum at Activated Intelligence because we earnestly wish to
support open standards well in our XML products, but the XSL working draft
specification requires  namespace support that apparently cannot be
implemented effectively if the primary input source is a dynamically built
DOM tree. It is impossible to overstate the business value and importance of
DOM trees as a form of input.

We have spent many long hours and many, many dollars evaluating the business
needs for XML/XSL - and our best insights suggest that DOM tree
representations will be the most natural and frequently occurring form of
in-memory representation of XML data.

Our XSL processor is designed to work with any XML parser that implements
DOM and SAX support - a fantastic benefit of reliance on open standards.
Unfortunately, if the DOM api is not rich enough to support namespaces in
XML effectively, then DOM becomes a second-rate interface for XML/XSL
application solutions.

There is no other object representation of XML data that even approximates a
standard as DOM does - and it is completely natural for programs to project
data that originates from databases and other sources though a DOM tree.
More importantly, if business logic must repeatedly access and manipulate
data sets that change only in minor ways over time, then it makes great
sense to act directly upon the in-memory DOM tree rather than reparsing XML
input over and over again.

LotusXSL is a rich and full implementation of the XSL spec, but it appears
to pay a dear price in performance for supporting both namespaces and DOM -
using a brute force solution that will not suffice for those who need to
perform hundreds of thousands or millions of XSL processing operations per
day.

And what else could they have done?

Perhaps gone the route of XT? Doesn't that mean there is then is no DOM
support at all - an even more extreme price - one which closes the door on
supporting any standard object representation of input data in XML parsers.
What application can afford to completely reparse input data every single
time XSL processing is desired?

Application business logic will be faster and more effective if it is
reliably able to operate on a DOM tree representation of the data it is
manipulating. If not DOM, then we NEED some other standard for this type of
representation - one which supports namespaces in XML the way they are
handled and specified in XSL.

Or else the way namespaces are handled in XSL needs to change...

It is not reasonable to discard the powerful value of DOM tree
representations of input data because the namespaces in XML recommendation
forces an either/or choice between DOM and namespaces. This is not an
academic problem, or even a computing science problem - it is straight
business - and the people who have drafted the spec have made an oversight
that simply demands correction.

We need a change that permits namespaces and DOM to co-exist in XSL without
requiring a huge performance penalty.

I hope others will share their comments, and that the XSL working group will
pay attention to whatever discussion ensues. Simply dismissing DOM is not an
acceptable option - since there is no alternative. Saddling XSL with a huge
performance hit due to unnecessarily required reparsing is also
unacceptable.

Surely there must be effective middle ground? I hope our dialog can reveal
it.

Rick Ross
Activated Intelligence, LLC

begin:vcard 
n:Ross;Rick
tel;fax:(212) 896-8222
tel;work:(212) 896-8220
x-mozilla-html:TRUE
org:Activated Intelligence
adr:;;100 Park Avenue;New York;NY;10017;US
version:2.1
email;internet:rick@xxxxxxxxxxxxx
title:President
note:Java Lobby - http://www.javalobby.org
x-mozilla-cpt:;32416
fn:Rick Ross
end:vcard