Subject: [xsl] well, well... microsoft xsl From: "Geert Bormans geert@xxxxxxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> Date: Wed, 31 Aug 2016 21:08:36 -0000 |
Maybe of interest to some of you I learned today that: - msxml has a maximum string-length for the concat of @select in a for-each and the @select of all the xsl:sort inside that for-each - that maximum string length is surprisingly small - that maximum string length differs with different versions of the dll or other mysterious environment settings not documented to my knowledge ... (and the number seems to become smaller with later dlls) - spaces (technically irrelevant to the XPath expressions in the @select, but used for pretty printing the complex expressions for readability) are added to that maximum count - msxml rejects stylesheets for this reason on static analysis, environment dependent, with no useful message other than " Object reference not set to an instance of an object." - it is a real fun if you hit that boundary and you are unaware of this mess If members of this list have come to similar conclusions, have been facing similar issues or did find references to documentation about this, I would welcome that very much (at least I managed to get my customer started on evaluating other transformers) Best regards Geert ----- Here is by the way a short story on how I came to those conclusions For one of my customers I have an XSLT 1.0 that is driven from a C# service they do on the .net framework Nothing really fancy, couple of thousand lines, some javascript extension functions for dates and strings and some use of the node-set extension, we are doing FO for PDF but that is irrelevant to the story The source XML has some complexity, long part lists with up to 20 maybe 25 language variant descriptions and the requirement to have an index with fall back languages (eg. if the Brazilian description is not available, use the Portuguese or... eventually use the English term if all others are missing) One of the potential languages is Simplified Chinese, so I also need some dynamic control over the @lang in the sorts No rocket science, but it leads to a somewhat longer @select in a for-each and maybe 10 xsl:sort inside that for-each Just explaining that for it is relevant to the story The following has been biting me for months (on and off) since I could not reproduce the problem The C# refused to load the XSLT on an occasional machine, with this message " Object reference not set to an instance of an object." No way for me to reproduce (except in Stylus Studio using the compiled .net transform, but that does not give extra information) No C# instantiation issues on any of my machines, no issues running from the different microsoft options in Oxygen... All production servers of the customers customer... no issues some development machines at the customer... same error, others, no issue weird, apparently no relation to the dll version A recent Visual Studio on a "faulty machine" managed to give the same error message on a static evaluation of the stylesheet, top level, no indication of the line number of the error, but at least we knew the error was "visible" to microsoft on static evaluation of the stylesheet My customer decided to cut lines from the stylesheet until the error disappeared and this way we have come to the above conclusion, it took them ages, but once we knew where to look, we made so many tests that we are pretty sure these conclusions hold
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] sequential numbering with, Heiko Niemann kontak | Thread | |
Re: [xsl] sequential numbering with, Heiko Niemann kontak | Date | |
Month |