[Home] [By Thread] [By Date] [Recent Entries]
Michael Kay wrote:
Error: Invalid QName {{'test'}}see XTDE1460 Aha, I see. That's what the double curly braces do in the error message... I didn't place them there... Workaround: if you want a literal value for format, use I will. Thanks. I used the AVT just to check if the AVT actually worked. I was surprised to find that: {'test'} failed {1} worked (but threw a dynamic error, of course) The general rule in XSLT is that attributes containing names of objects An exception and the base rule in one instruction element for (imho) similar attributes. The reason for the rule is to allow character maps to be Just an idea, but has anybody ever thought of the possibility of "Static" AVT's? Like, say, global parameters and/or variables or anything else that can be determined at compile time, a bit similar to a static value, or a derived constant value in traditional imperative programming languages? Than you would not loose the hash-table optimization, and you would add to the language the configurability of these attributes. IMHO, that would greatly increase the adaptability and usability of XSLT as a whole. XSLT 2.1? ;-) Many products, including Saxon, allow you to control the serialization Thanks, that might be it. In our current policy, we have the role "programmer" and XSLT designer. And we try to give the XSLT designer as much as possible freedom in configuring the XSLTs he/she creates. But I'll find a way, surely. With doc()/document(), you can control such preprocessing using a And using the suggestion from Dave? Using a codepage resolver (or how do you call it?) and inventing custom codepages, which act as filters, sounds like a workable solution. Would that work for unparsed-test()? Cheers, Abel
|

Cart



