Re: [WiX-users] XmlFile - specification misimplementation

[Michael Cline]

It appears to me that maybe there is a simple resolution.  When Darren mentioned that he couldn't use the 'last()' function I begin to look at how MSXML implemented the stuff.  It looks like if you just use the XMLDOM out of the box it isn't using XPath but rather XSLPattern http://windowssdk.msdn.microsoft.com/en-us/library/ms766391.aspx   I think that some of the issues people are having would be resolved by setting the SelectionLanguage property on the document that is being loaded.  Since the documentation states that 'ElementPath' is 'The XPath of the element to be modified', the default use of XSLPattern seems to cause people much confusion.   Should I open a bug for this change or is this something that is irrelevant because K is going to be reworking the stuff?     ----- Original Message ----- From: Darren Kulp To: wix-users@lists.sourceforge.net Cc: Darren Kulp Sent: Wednesday, July 05, 2006 3:33 PM Subject: [WiX-users] XmlFile - specification misimplementation 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 [EMAIL PROTECTED]   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

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