Gopal Sharma wrote:
> Can we talk about the approach of you & discuss about the complexities you
> may have faced during porting work?
Sure. Basically the problems areas that I encountered were:
1) The internal API is different. This was not that troublesome
at first until I realized that the required changes kept
cascading into bigger and deeper problems.
For example, Xerces 1.x uses integers that represent strings
and symbols in the StringPool. Since Xerces2 uses the native
Java String object, I had to convert all of the uses of
these integers into Strings. This problem lead to me next
issue.
2) The string pool indices were overloaded with special meanings
throughout the parser. Since *everything* was an integer id
in Xerces 1.x (strings, element decl indexes, content spec
node indexes, etc), there are certain structures that will
use this knowledge to overload the use of an integer storage
in the structure.
For example, the content spec nodes have integers that will
either point to a symbol in the string pool or to another
content spec node (in order to build up a tree structure of
the content model) depending on the type of the node.
This is perhaps the hardest part because it means that a) you
have to change all of the structures and the code that calls
it, and b) you have to know what each integer id was used for
so that you convert the code correctly.
3) There were some dependencies on parser components that no
longer exist in the same form in Xerces2. For example, some
of these parts have hard-wired dependencies on certain old
implementation classes.
For example, there were parts that required the old
XMLEntityHandler to be passed around and used. However, this
component doesn't exist in the same form in Xerces2. And more
over, the thing that replaced it (e.g. XMLEntityManager) has
completely different behavior and interaction within the
parser.
> Is the ported code available in "ported code: "valport_x2" branch ?
No. It's only on my local machine. But I could put it into the
branch for you to take a look at and hopefully continue the
porting effort. I'll put that on my list of things to do today.
I hope that I get it done before the weekend here but I'm
trying to post the Xerces2 beta today. :)
Some important things to be aware of. First, I created a new
package called "v1" under the "org.apache.xerces.impl" package.
I've been moving all of the Xerces 1.x validation code here so
that I don't pollute the main Xerces2 branch. And since Xerces2
is modular, I can create local configuration objects to test
out the changes without modifying any of the existing Xerces2
parsers. (I use the xni.* samples to do this -- xni.Counter
and xni.Writer, for example.)
It's my intention that the validation engine redesign work
would then go under a new package called "v2" from the impl
package. That way work on both can proceed in parallel, again
not affecting the main Xerces2 branch.
Then when the port is finished, "impl.validation" can be
removed, and the standard configuration would be modified
to use the "v1" validation engine. And when the whole
redesign is done, then the "v1" validation engine can be
swapped out for the new "v2" validation engine. (This is all
assuming that a port of the Schema code would be finished
long before the new design was implemented and ready for
prime time, of course.)
So what do you think? Are you ready for the challenge? :)
--
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
