Thanks again! From: Rob Mensching
[mailto:[EMAIL PROTECTED] 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 |
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
