Now that v2.6 is out-the-door I am starting work on v3.0
of the TclXML/TclDOM/TclXSLT family. The CVS modules
for each of these packages have had a branch created -
"v3_0" is the branch name.
This leads me to the issue of release management.
ActiveState pull the HEAD of the CVS modules for inclusion
in ActiveTcl and TclDevKit. Now, this means that
(a) there are problems when the head is unstable,
and (b) the package as included in ActiveTcl/TclDevKit
may be different to the last stable release even though
the version number is the same.
In order to workaround these issues from this point
forward all development will occur in branches of the
package modules. When the package(s) is(are) released
the branch will be merged with the HEAD. This should
make releases more "atomic". I note that other projects
have introduced a similar policy (TclSOAP, as I recall).
The design of v3.0 of the packages is now under consideration.
All suggestions are welcome. My main aims with this
version are as follows:
1. Bind to libxml2 in the TclXML package, exposing libxml2's
SAX interfaces. TclDOM/libxml2 will call into TclXML
to perform parsing, rather than directly invoking libxml2
parse functions. Also allow parsing options to be passed
from TclDOM to TclXML. This will allow applications to
parse an XML document into a DOM tree, but simultaneously
interpose on the SAX events while parsing is performed.
2. Develop a binding to MSXML. MSXML is a well-regarded
XML parser and XSLT engine, which is reason enough to
do a binding, but I'm particularly interested in its
XML Schema validation capability. NB. I'm not very
well geared-up for Windows app development, so any
help would be appreciated - especially any form of
sponsorship.
3. Change the model for managing libxml2 tree nodes in
TclDOM. There are some fundamental flaws in the
current model:
a. The one-to-one mapping of Tcl objects to tree nodes
breaks down, since multiple Tcl objects may have
a pointer to the same libxml2 node.
b. Using the _private field to point back to the
Tcl object conflicts with libxslt.
Changing the model should allow us to fix memory leaks,
see bug #637578.
4. API and implementation changes: I've always been reluctant
to define node commands (as tDOM does), because of the
potential impact on the performance of the Tcl interpreter
of possibly thousands of commands being defined (not that
I've done the work to confirm that there is an impact).
However, in a recent brainwave I thought it would be cool
to create a separate Tcl namespace for each DOM document.
Cleaning up the document will then trivially easy
('namespace delete $doc') and node commands will be isolated
in that namespace, therefore avoiding impact on other
parts of the interpreter.
5. Hook into the safety aspects on libxml2. In fact, it may
be interesting to create "Safe XSLT" - linking an XSLT
stylesheet to a safe Tcl slave interpreter.
Would folks find it convenient to put the above into a
Wiki page?
Feel free to share your thoughts...
Steve.
--
Steve Ball | XSLT Standard Library | Training & Seminars
Zveno Pty Ltd | Web Tcl Complete | XML XSL Schemas
http://www.zveno.com/ | TclXML TclDOM | Tcl, Web Development
Ste...@zv... +---------------------------+---------------------
Ph. +61 2 6242 4099 | Mobile (0413) 594 462 | Fax +61 2 6242 4099
|
