From: Derek F. <fo...@hu...> - 2002-09-27 14:38:01
|
I'm trying to work out the status of CDATA support in text nodes in various versions of ActiveTcl. I have this little test script: --- #!/bin/sh # \ exec tclsh8.3 "$0" "$@" package require xml package require dom set xml {<test><![CDATA[Some text with a <br/> in it]]></test>} set docNode [::dom::DOMImplementation parse $xml -parser tcl] set elementNode [dom::node cget $docNode -firstChild] set textNode [dom::node cget $elementNode -firstChild] puts [dom::node cget $textNode -nodeValue] --- With ActiveTcl-8.3.4.3 this returns an empty string. If I remove the -parser option, it returns the CDATA text. Unfortunately, the default parser is too buggy - I need the tcl parser to make the rest of my script work. ActiveTcl-8.4.0.1 doesn't have the -parser option (I thought it used the same Tcldom package as 8.3.4.3, but must be mistaken), and has other issues in other places which prevent my script working. Basically, I want to stick with ActiveTcl-8.3.4.3, and the tcl parser, and get the text from CDATA sections. Can I do that? -- 3:28pm up 65 days, 5:56, 2 users, load average: 0.02, 0.13, 0.09 |
From: Steve B. <Ste...@zv...> - 2002-09-29 20:23:52
|
Derek Fountain wrote: > I'm trying to work out the status of CDATA support in text nodes in various > versions of ActiveTcl. I have this little test script: [...snip...] Script looks fine to me. > With ActiveTcl-8.3.4.3 this returns an empty string. If I remove the -parser > option, it returns the CDATA text. Unfortunately, the default parser is too > buggy - I need the tcl parser to make the rest of my script work. > > ActiveTcl-8.4.0.1 doesn't have the -parser option (I thought it used the same > Tcldom package as 8.3.4.3, but must be mistaken), and has other issues in > other places which prevent my script working. > > Basically, I want to stick with ActiveTcl-8.3.4.3, and the tcl parser, and > get the text from CDATA sections. Can I do that? Basically I'd say the version of TclXML and TclDOM that shipped with ActiveTcl 8.3.4.3 were buggy. ActiveTcl 8.4.0.1 would be using more recent versions, which have different bugs (like the lack of a '-parser' option). Please submit bug reports for those problems. It should not be difficult to adjust the packages being loaded in ActiveTcl 8.4.0.1 to use the pure Tcl implementations. Firstly, make sure you have the latest release: v2.3. Secondly, use 'package require tclparser' to load the pure-Tcl parser first and make it the default parser. Failing that, remove the TclXML/TclDOM DLLs to force the pure Tcl packages to be used. HTHs, Steve Ball -- 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 |
From: Derek F. <fo...@hu...> - 2002-09-30 10:02:34
|
> Basically I'd say the version of TclXML and TclDOM that shipped with > ActiveTcl 8.3.4.3 were buggy. ActiveTcl 8.4.0.1 would be using more > recent versions, which have different bugs (like the lack of a '-parser' > option). Please submit bug reports for those problems. > > It should not be difficult to adjust the packages being loaded in > ActiveTcl 8.4.0.1 to use the pure Tcl implementations. > Firstly, make sure you have the latest release: v2.3. > Secondly, use 'package require tclparser' to load the pure-Tcl > parser first and make it the default parser. Failing that, remove > the TclXML/TclDOM DLLs to force the pure Tcl packages to be used. Unfortunately, plugging new versions of libraries in isn't really possible for my project. I have to distribute some code across my department, and one of the conditions of my doing it in Tcl as opposed to C++ was that I just distribute a single binary. I haggled such that installing one, easy to install package (ActiveTcl in this case), as well as the "binary" would be acceptable. The users can manage that on both Win32 and Linux. Patching in various versions of libraries is something I really need to avoid if possible. I've been having a better look at ActiveTcl-8.4.0.1 and seem to have it running the pure tcl parser by putting "package require tclparser" just after my "package require xml". (How do I tell which parser it's using?) The problem that appears now is that an area of text inside a CDATA section might get serialised such that it doesn't have the CDATA wrapper on output - the meta characters get escaped individually. Looking at the code, there seems to be a "node:cdatasection" flag on the node which is used to preserve these CDATA wrappers. However, I'm not sure this flag is being set properly a parse time. It certainly doesn't seem to be working for me! Unfortunately I need those CDATA wrappers to stay in place, but only where they appear in the input (so setting ::dom::maxSpecials to 0 doesn't help). They are being used to protect HTML areas in the text which a guy downstream is having to jump through some serious XSL hoops to get rendering right. Strictly speaking I think he's doing kludgey things, using "CDATA" as markers for certain behaviours, but I can't change what he's doing. Is there any way I can get that node:cdatasection flag to work correctly? -- 10:45am up 68 days, 1:12, 2 users, load average: 0.00, 0.02, 0.00 |
From: Steve B. <Ste...@zv...> - 2002-09-30 20:54:25
|
Derek Fountain wrote: > I've been having a better look at ActiveTcl-8.4.0.1 and seem to have it > running the pure tcl parser by putting "package require tclparser" just after > my "package require xml". (How do I tell which parser it's using?) ::xml::parserclass info default > The problem that appears now is that an area of text inside a CDATA section > might get serialised such that it doesn't have the CDATA wrapper on output - > the meta characters get escaped individually. Looking at the code, there > seems to be a "node:cdatasection" flag on the node which is used to preserve > these CDATA wrappers. However, I'm not sure this flag is being set properly a > parse time. It certainly doesn't seem to be working for me! > > Unfortunately I need those CDATA wrappers to stay in place, but only where > they appear in the input (so setting ::dom::maxSpecials to 0 doesn't help). > They are being used to protect HTML areas in the text which a guy downstream > is having to jump through some serious XSL hoops to get rendering right. > Strictly speaking I think he's doing kludgey things, using "CDATA" as markers > for certain behaviours, but I can't change what he's doing. > > Is there any way I can get that node:cdatasection flag to work correctly? You and the downstream guy need to get a better understanding of exactly what your XML documents contain. Consider these two documents: <Example><></Example> and <Example><![CDATA[<>]]></Example> They are EXACTLY the same document. CDATA Sections are simply a syntactic convenience to save having to escape individual characters. TclXML and TclDOM operate at a slightly higher level than the raw XML syntax; the XML Infoset. TclDOM manages the raw syntax on your behalf. In the case of text nodes, if the number of special characters exceeds some threshold then it will automatically use a CDATA Section. You may like to investigate playing around with the threshold value... The other thing to note is that if the downstream guy is using XSLT then I don't understand why the use of CDATA sections (or not) is an issue at all. XSLT never even sees the CDATA sections - they get transparently turned into text nodes before template processing begins. This one of the major differences between the XPath and DOM data models. Summary: relying on the use of CDATA Sections in an XML document is bad application design. HTHs, Steve Ball -- 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 |