Re: [xsl] result-document, QNames, AVT's, format-attribute and use-chara

Michael Kay wrote:
> > Error: Invalid QName {{'test'}}see XTDE1460
> >     
> Because there's a bug. It parses the AVT and if the result is a string
> constant then it assumes you wrote format="test" and uses the attribute
> value as written. 
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
> format="test".
>   
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
> > defined in the stylesheet are not AVTs. The format attribute of
> > xsl:result-document is a rare exception. The use-character-maps attributes
> > sticks to the rule. 
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
> > compiled into hash tables or similar structures at compile time, with the
> > knowledge of which character maps are actually referenced and which aren't.
> >     
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
> attributes (or indeed the whole serialization process) from your Java
> application. You may find this is a more flexible approach.
>   
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
> URIResolver - the best way is to insert a SAX filter between the XML parser
> and the XSLT processor. There's no similar capability for unparsed-text() in
> Saxon at the moment, but you can write your own extension function to do it.
>   
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

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--