Bugs item #1381029, was opened at 2005-12-15 01:41 Message generated for change (Comment added) made by drieseng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1381029&group_id=31650
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Documentation Group: 0.85 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: LWeimer (sand0z) >Assigned to: Gert Driesen (drieseng) Summary: Expression evaluation less than or equals requires < Initial Comment: I'm using nant build 0.85.2143.0; nightly 11/13/2005. I want to see if one integer is less than or equal to another. That is, compare to integers using <= 1. So I write my test: <if test="${5 <= 0}" > <echo message="Val 1 not-less-or-equal-to 0 or less." /> </if> I shouldn't get a: "Error loading buildfile. '<', hexadecimal value 0x3c, is an invalid attribute character, Line 159, position 20." (I've attached the stack trace) 2. If I go: >=, as in: <if test="${5 >= 0}" > <echo message="Val 1 not-less-or-equal-to 0 or less." /> </if> Things work fine. 3. If I go: <= <if test="${5 <= 0}" > <echo message="Val 1 not-less-or-equal-to 0 or less." /> </if> Things work fine. 4. If I go: == <if test="${5 == 0}" > <echo message="Val 1 not-less-or-equal-to 0 or less." /> </if> Things work fine. Thanks for looking into this! If a bug has already been submitted for this, please forgive, I did do some searching to see if this bug existed, but if something was there, I couldn't find it. ---------------------------------------------------------------------- >Comment By: Gert Driesen (drieseng) Date: 2006-03-06 20:40 Message: Logged In: YES user_id=707851 I've added the following note to the Expressions doc page: Expressions are often used in XML attributes. The grammar specified in this section applies to the attribute value after XML 1.0 normalization. So, for example, if the grammar uses the character <, this must not appear in the XML source as < but must be quoted according to XML 1.0 rules by, for example, entering it as <. ---------------------------------------------------------------------- Comment By: dries (verbedr) Date: 2006-02-24 17:41 Message: Logged In: YES user_id=1217017 I guess you should take this up at W3C as this is standard xml behaviour and no bug or flaw. This is documented at http://www.w3.org/TR/REC-xml/#sec-predefined-ent. The reason why > is working and not < is because the xml parsers knows that a > character can only be followed after a < character and thus can make a clear distinction. The confusing part is that the parser tries to be a little less restricting and makes an educated guess. But as a general rule use the entity's declarations. And in doubt try to open the build file with any xml viewer (like Firefox or IE). ---------------------------------------------------------------------- Comment By: Christian Birkl (wingmansf) Date: 2006-02-24 13:29 Message: Logged In: YES user_id=934713 This bug is not valid because this is an xml issue and won't be fixed in the xml standard. Perhaps this bug should be closed then? Perhaps catching this XmlException and printing out a nicer error message than "'<', hexadecimal value 0x3C, is an invalid attribute character" like: NAnt's xml parser has detected an invalid character at line x,y: Please rewrite the expression ">" as ">" because this character cannot be used within an attribute value. ---------------------------------------------------------------------- Comment By: Victoria French (metrosharp) Date: 2005-12-16 14:06 Message: Logged In: YES user_id=305495 I agree that writing a custom XML parser would not be worth the effort to correct an XSLT problem, but I can see from a usability point of view that creating a resolution for this issue is. I don't believe that a user of NAnt should have to understand the rules and complexities of all the underlying technology such as XSLT to use the product. While most of the users of NAnt are technologoy users, there are some working in QA and Build labs who are not as knoledgable on these issues. Perhaps a simple solution to the issue would be to load the XML and correct these types of issues via RegEx replace before loading the file into an XmlDocument and performing a Transform. Not only would this allow for the correction of this issue, but would create a path for correcting any other issues similar to this that might arise in the future. The question I have is would this have a negative impact on the product? ---------------------------------------------------------------------- Comment By: Martin Aliger (maliger) Date: 2005-12-16 09:36 Message: Logged In: YES user_id=655297 Since NAnt build file is built upon XML (not html!), read "by design" as XML reader limitation. Try to look to some XML Tutorial or Reference. For example: http://skew.org/xml/tutorial/ chapter "5.3. Character data" What you are saying about lt and gt is completely true, and it is complete description of this limitation. I'm sorry if I choose poor words. I'm not native speaker after all :-) I still think, we should add a line or two about it into docs. There should be something, imho... ---------------------------------------------------------------------- Comment By: Gary Feldman (garyfx) Date: 2005-12-16 01:20 Message: Logged In: YES user_id=847172 I think that "by design" was a poor choice of words. It's part of the design of XML, not NAnt. When NAnt, following in the footsteps of Ant (and everyone else), chose to use XML as the basis for its input, it inherited all of the limitations that XML imposes. XML simply will not allow the less-than symbol to appear inside an attribute string. You can try it yourself - create a file containing just "<tag attr="abc<def" />", being sure to name it as a .xml file, and try opening it directly in your browser. Change the < to > and try again. NAnt uses the .Net XML parser, and that's the way life is. In theory, one could write a non-compliant parser that would handle these, but it wouldn't be worth the effort for this one particular case. ---------------------------------------------------------------------- Comment By: LWeimer (sand0z) Date: 2005-12-15 17:13 Message: Logged In: YES user_id=1338161 I'm not sure what you mean, "by design". I'm not sure why <= doesn't work but ==, and >= works. If you can get == and >= working, then <= should work also. It seems like a bug, not an inherent flaw. Perhaps I completely misunderstand what you have said. Could you clarify what you mean? < for that mater > (ie, less than, greater than) I'm not sure where it comes from either. I know it is something that you can use in html to get < and > to render ok on web pages. I used it because I used the " and > before to work around another problem where I needed quotes within quotes and a > (redirect, also a "greater than")... (so I tried < and it worked) see? <echo append="True" file="encryptor.bat" message="${g_HexBin}\Encryptor.exe "${g_KeyFile}" "${g_FileToEncryptPath}\${g_FileToEncrypt}" ${g_EncryptFlags} > ${tEncryptionOutFile}" /> created a encryptor.bat file with a single line that looked like: c:\somedir with a space\Encryptor.exe "ceasar.txt" "c:\somedir with a space\somefile.txt" -e > outfile.txt ---------------------------------------------------------------------- Comment By: Martin Aliger (maliger) Date: 2005-12-15 07:53 Message: Logged In: YES user_id=655297 This is "by design". In fact everything built atop of XML have this flaw. XSLT comes to my mind, but there are alot of technologies around. Maybe we should stress this fact in documentation. I was unable to find any mention of < at all. (expression page?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402868&aid=1381029&group_id=31650 ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers