|
1. The XPath processing is handled by MSXML. We’re
at the mercy of any bugs/non-spec compliance they have. 2. The create/modify pattern is exactly what was discussed
and will be changing as K gets time. 3. “Time wasted discovering this sort of error”
is time that someone has to spend somewhere. Ideally we capture the time
spent such that others can learn from who ever hit it first. I see that
you opened a bug on the issue, thanks much. I’m not sure there is
much we can do about it (save switching to a completely different XML/XPath/XSL
processor... something I’m not too keen on) but hopefully it’ll
save other people time. 4. As for a robust test suite, there has been discussion about
this but nobody has done the work yet. Would you like to lead the charge
here and start developing it? From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Darren
Kulp A
conversation between Michael Cline and Rob Mensching has clarified the state of
XmlFile, but in case this information can help anyone else, or someone can
suggest a workaround to my problem, I hereby submit the results of some recent
research on XmlFile. XmlFile’s
XPath implementation is incorrect with regard to position indexing.
Specifically, the first “proximity position” (or NodeSet index) in
the XPath specification is 1 (http://www.w3.org/TR/xpath#dt-proximity-position);
in XmlFile, it is 0. In the following example XML file, /abc/mult[1]
refers to the only <mult /> element in the file, but specifying this path
will cause XmlFile to throw an error, saying the node could not be found (using
“/abc/mult[0]” returns the result we had expected): <abc>
<mult>a</mult> </abc> In
addition, XmlFile does not appear to support the last() function. This
is a severe disadvantage with the current create-then-modify implementation,
since as far as I can see (though I am an XPath newbie), it is necessary to use
last() if one wants to add, for example, a <CodeGroup /> to
.NET’s security.config; because there are multiple <CodeGroup />
elements already, we can know which one we have just created only by the fact
that it was the last added. This is the problem for which I need a
workaround if anyone has one; since last() always fails, I do not know how to
specify a just-added node for future modifications. I have a working
demonstration of both these bugs which I shall submit to the SourceForge bug
tracker directly; I haven’t yet got the WixCA to build under VS.NET 2003,
but if I succeed I will try to submit patches as well. I
want to express my appreciation for the WiX toolset, but the time wasted
discovering this sort of error can be significant. Has there been any
consideration of a robust test suite for code like this? Darren
Kulp WAUSAU |
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
