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

Subject: Re: [xsl] result-document, QNames, AVT's, format-attribute and use-character-maps attribute
From: David Carlisle <davidc@xxxxxxxxx>
Date: Thu, 14 Dec 2006 12:47:01 GMT
> It puzzles me, that xsl:attribute, which has the same AVT datatype for a 
> the name-attribute, does not behave in the same way

It looks to me from the spec as if format is allowed to be an AVT but
from your posted error message, that saxon isn't supporting that at
present. Actually it's quite surprising that this is an AVT as (like
name= on call-template) it's a reference to a named stylesheet
construct, which normally in xslt are compile-time constructs, however
the spec clearly shows this as an AVT so I think it's supposed to work.

> 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)
well use-character-maps is again a reference to a stylesheet construct

>  (reason: I want to 
> strip or replace unparsable bytes from the input stream before it gets 
> to the XSLT processor, which would reject any \x00 and, depending on 
> version, other control characters).

There's no way to do that without using an extension function.
(actually there is, you could specify that the file is in some
custom-encoding, but then you'd have to supply the encoding handler to
saxon so it's probably as easy just to directly use an extension
function) I think it would have been useful if the data model had
allowed non-xml characters, just as it allows trees that can not be
serialised as an XML document, then the unparsed-text() function could
have been a more general text includer, andxslt regexp could have been
used to clean out control characters, but this was explictly raised and
they decided not to do it, you can't have everything:-)

David

Current Thread