[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

RE: [xsl] result-document, QNames, AVT's, format-attribute and use-character-maps attribute

---

---

> Q1: why does the QName of the format-attribute raise an error 
> is specified as literal AVT? I use Saxon 8.8.
> Example:
>     <xsl:result-document href="xyz.xml" format="{ 'test' }">
>           ....sequence....
>     </xsl:result-document>
> 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. Workaround: if you want a literal value for format, use
format="test".

> 
> Q2: Is there any plausible reason why all attributes have 
> become AVTs, with the exception of use-character-maps (and 
> validation/type, but that sounds sensible)? 

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. 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.




> I really want a 
> user-specifiable filter for result trees, but it does not 
> appear to be possible (unless: I create one xsl:output per 
> filter, or combination of filters, and use the 
> format-attribute). The specs says so as well. Am I correct?

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.
> 
> Q3: Though an serialization can be mapped with a character 
> map, is anyone aware of a similar function with "importing" 
> data? Like, with the
> doc()/document() functions, or, better yet, with the 
> unparsed-text() entry? Or should I stick with extension 
> functions? 

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.

Michael Kay
http://www.saxonica.com/

---