If Xerces is so bad why host it at xml.apache.org. I agree about the
footprint requirements & reference counting issues, but does that not make
programming simple for people. Now a 64 Bit UltraSparc sells for less than
$2000 where is the issue of performance (though some systems might still cry
foul, but those are less than 1% of the systems). I would rather want to see
software being built which is easy to code & manitain & not have core
dumps:).
Since both XSLT+XPath products are called Xalan it was also expected of
apache to have the same API for both C++ & Java implementation.
I guess now I wil have to write my own support for XPath for Xerces.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 21, 2001 11:18 AM
To: [EMAIL PROTECTED]
Subject: RE: Xerces DOM Objects & Xalan
Rajan,
Sorry, there is no way around this except by using the bridge. There has
been ample discussion of this on the mailing list, and if you search the
archives you can read everything that has been said about it.
This is not, as you might think, a failure of Xalan. This is a result of
the decisions the implementors of Xerces made when they wrote their DOM.
The reason the Java products work together is that they conform to the
standard DOM Java interfaces established by the W3C DOM working group.
Unfortunately, the working group did not create a set of C++ abstract base
classes -- they only created CORBA IDL bindings.
This mismatch might have been avoided had the implementors of Xerces
created abstract base classes and derived their DOM from those classes, but
they did not. So without this, there was no way to provide a reasonable
implementation of an XSLT source tree for use in Xalan-C++. And believe
me, if we relied on the Xerces DOM as our source tree, Xalan-C++ would be a
rotten XSLT processor. The Xerces DOM has a truly horrible memory
footprint and is very slow due to its use of reference counting and
synchronization. Ironically, these characteristics resulted in the
implementation of the Xerces IDOM, which is a much better implementation
built on a set of abstract base classes. Unfortunately, this was not
finished until recently, and it's way to late to think about completely
rewritting Xalan to use it directly.
There are many Java-based XSLT processors which also require building their
own internal tree for doing processing. They only accept DOM to generate
this tree, which they then transform. There are many good reasons to do
this, one of which is that the XSLT source tree and DOM have differences
that seem minor, but are, in reality, quite significant. In fact, the
latest versions of Xalan-J use a new internal model, called the DTM. If you
pass in a DOM source, Xalan will build a DTM model of that DOM and
transform the DTM, so you're right back where you started from since you
still have two copies of the document.
Dave
"Gupta,
Rajan" To: [EMAIL PROTECTED]
<rgupta@eshar cc: (bcc: David N
Bertoni/CAM/Lotus)
e.com> Subject: RE: Xerces DOM Objects
& Xalan
09/21/2001
09:25 AM
Please
respond to
xalan-dev
David,
I did. What I saw was that I had to create XalanBridge objects for Xerces
objects to work with Xalan. Please correct me if I am wrong here.
If my understanding is correct, I think this will be a huge overhead for to
use xalan with xerces.
Please advise. i have used xerces objects thru. out, now I cannot just
insert xalan code in places, without going thru a bridge.
I have used Xerces & Xalan for Java, & they integrated seamlessly. I
expected the same with C++ version & even the API between Xalan C++ & Xalan
Java to be the same. I am sure you all have a slick way of doing it without
creating bridges, which I am sure I have missed. Can you please point me to
a sample for using Xalan without using bridges in the middle. I expected
the
DOM_Node * XPathEvaluator::selectSingleNode (DOMSupport & domSupport,
DOM_Node* contextNode, const DOM_String* xpathString..)
Please advise what people who have used Xerces extensively should do to use
Xalan to use XPath in their code.
Thanks.
Rajan
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 20, 2001 5:36 PM
To: [EMAIL PROTECTED]
Subject: RE: Xerces DOM Objects & Xalan
Why are you saying there's no compatibility layer? Did you read the
documentation? There _is_ a compatibility layer that allows you to use the
Xerces DOM with Xalan.
There is no way that Xerces can be "dropped" in favor of Xalan. Xerces is
an XML parser which also has a DOM implementation. Xalan is an XSLT
processor, which is something quite different from an XML parser. Xalan
uses Xerces as its XML parser, but we do not use the Xerces DOM as our
default XSLT source tree because the performance would be horrible and
would not allow for alternate source tree implementations to be used with
Xalan.
Please, read the documentation, and look at the sample applications. If
you still cannot understand how to use the Xerces DOM with Xalan, then
search the mail archives. If you still then cannot understand how the two
can be made to work together, then post your questions to the list.
Dave
"Gupta,
Rajan" To: [EMAIL PROTECTED]
<rgupta@eshar cc: (bcc: David N
Bertoni/CAM/Lotus)
e.com> Subject: RE: Xerces DOM
Objects
& Xalan
09/20/2001
03:39 PM
Please
respond to
xalan-dev
I am using Xerces DOM & I create a DOM document on which I want to apply an
xpath to get a node. Will this be a correct statement :
"Xalan-C does not work with Xerces DOM Documents".
Now I will have to rip out Xerces from my framework & use Xalan DOM
instead.
What I am missing here is if both Xalan-C & Xerces-C were done under the
Apache SF why there is not compatibility layer.
It would be insightfull for me if somebody could tell me if Xerces is going
to be dropped in favour for Xalan?
It may be noted that Xalan-J works with Xerces-J which made life so simple.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 20, 2001 2:32 PM
To: [EMAIL PROTECTED]
Subject: Re: Xerces DOM Objects & Xalan
Yes, there are some very good reasons. A couple of them are:
1. The Xerces DOM_* interfaces are smart-pointers. They do not provide
an abstraction upon which to build an alternate implementation.
2. The original Xerces DOM does not have good performance or memory
usage characteristics.
If you read the documentation, you will discover that the topic of wrapping
the Xerces DOM for use in Xalan is discussed. If you are not using the
Xerces DOM for any particular reason, you should use Xalan's proprietary
source tree, as the performance is much better. For more information, you
can search the archives of the mailing list:
http://marc.theaimsgroup.com/?l=xalan-dev&r=1&w=2
Dave
"Gupta,
Rajan" To: [EMAIL PROTECTED]
<rgupta@eshar cc: [EMAIL PROTECTED],
(bcc: David N
e.com> Bertoni/CAM/Lotus)
Subject: Xerces DOM Objects &
Xalan
09/20/2001
02:24 PM
Please
respond to
xalan-dev
Hello! All,
I have a design question on using Xalan with DOM Documents generated via
Xerces. How can I apply an XPath expression on a DOM_Document as defined in
<dom/DOM_Document.hpp>
I notice in the samples provided that Xalan uses its DOM hierarchy such as
XalanDocument. Was there any specific reason not to use the objects defined
by Xerces or I am missing something.
Thanks
Rajan
