> I hope to give this a try later today. Does this mean though
that
> the Xerces document is copied into a Xalan one? I'm just thinking that
for
> the kind of work I do, if this were the case, it'd be a huge performance
> hit.
It's bad, but it's not quite that bad. We _do_ have to create a bridge
node for every node in the document, but we don't copy the data. In
addition, there are many optimizations to help reduce the memory overhead
when we allocate the bridge nodes. You'll also find that traversing a DOM
using our bridge can actually be faster than traversing the Xerces DOM,
since there's no reference counting involved with our wrapper.
That said, there _are_ problems with the bridge, as there will be
significan memory overhead with large documents. It's unfortunate, but we
just can't use the Xerces DOM as our native one, as the performance is
horrible, and the DOM_Node classes are not polymorphic.
> I'd also like to step back, and just explain my intentions
> here. My company uses a custom scripting language in its day to day
> operations. When we were first developing this language, we looked at a
> few XML technologies, and decided that at the time, Xalan didn't meet our
> needs, and used Xerces instead.
> At the time, XPath didn't exist, and we ended up implementing
> something very similar, which was then later modified to support
> XPath. Due to our business requirements, we've enhanced this
> implementation a bit with custom functions, and the like.
> I'm not suggesting incorporating our module into the
> official Xerces distribution. We're wanting to offer this module to
anyone
> who might find it useful, in the spirit of open source. It could very
well
> be the case that it's completely redundant in light of Xalan's XPath
> implementation. However, while we're going to take a closer look at what
> Xalan currently implements, we still feel that our implementation has its
> merits, and would be of use to some people.
Although my initial response may have seemed negative, I don't have any
objections to this. Xalan should stand on its own merits, not because it
was there first. If you're willing to offer your code, and people find it
useful, I think that's great. Xalan is not some Swiss Army knife that does
everything better than anything else, nor is it necessarily the best
XPath/XSLT engine in existence.
Also, any feedback and/or contributions to Xalan will be most welcome!
> That being said, I'd like to ask my original question again. For
> anyone that would be interested in using this under windows, can you
> advise me on how to implement the project and changes to the Xerces
> code. Because I end up with mutually dependent libraries, VC++ isn't
happy
> with it. The quick and easy thing to do is incorporate the whole of the
> module into the XercesLib project. But is there a better, or preferred
> way?
How are you solving the dependency issues on Linux/Unix? If you're just
building your code into the shared library, you can certainly do the same
on Windows -- just add your code to the Xerces project file, and it'll be
compiled and linked in. Another way is to do a two-step linking process.
You can do this by forcing the linker to generate the output files, even
though there are unresolved symbols. This will generate the .lib file for
each DLL. Then, you just delete both DLLs and link again. Awkward, but it
works. See:
Project | Project Settings | Link | Customize | Force file output
from the main menu bar in the IDE.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
