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
Steve.Ball@[...].com  +---------------------------+---------------------
Ph. +61 2 6242 4099   |   Mobile (0413) 594 462   | Fax +61 2 6242 4099



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tclxml-devel mailing list
Tclxml-devel@[...].net
https://lists.sourceforge.net/lists/listinfo/tclxml-devel