Re: [xsl] list of actual attributes?

Subject: Re: [xsl] list of actual attributes?
From: David Carlisle <davidc@xxxxxxxxx>
Date: Fri, 8 Apr 2005 10:56:33 +0100
> I could have used <xsl:copy> instead of <xsl:element name="{name()}">, but I don't see what I'd
> gain.  (perhaps someone can explain?) 

you get a potentially different result.

xsl:copy gives you an element with the same local name and namespace as
the source element and also the same in scope namespace nodes. In most
systems it probably uses the same namespace prefix as in the source but
this isn't guaranteed.


<xsl:element name="{name()}">

gives you an element with local name the same as the source local name
and prefix that reported by name() which is always in my experience the
prefix used on the source file (although this is not guaranteed)
however the namespace used with this prefix  in the result tree is the
namespace bound to this prefix _in the stylesheet_ which may be
different or may be an error if this prefix is not bound. Other inscope
namespaces on the source element are not copied, unlike the case for
xsl:copy.


        <xsl:for-each select="@*">
        <xsl:attribute name="{name()}">
        <xsl:apply-templates select="."/>
        </xsl:attribute>
        </xsl:for-each>


apart from similar comments regarding edge cases with namespaces that is
equivalent to
<xsl:copy-of select="@*"/>
ie a copy of all the attributes.

> Also, AFAICT, using <xsl:copy-of> would not work when I need to apply separate templates to
> individual children?


correct.

> Anyway, the problem I'm experiencing is - the list of attributes that I get using '@*' seems to
> also include the attributes with default values from the DTD.  How do I get the list of
> actual attributes as used in the source document?

You don't. The attributes are added by the DTD by the XML parser before
XSLT starts and XSLT has no record of the difference. The whole point of
attribute defaults are to _save_ later applications having to special
case code for attributes being there or not being there, by normalising
things so they are always there. If the non-appearence of an attribute
has a significance then the DTD should mark it as #IMPLIED rather than
supplying a default, to allow an application such as XSLt to "imply"
some default behaviour.

I dont't know xalanc but in many systems it is possible to supply an
entity resolver or catalogue to customise how dtds and other files are
fetched, if that is possible here you could arrange things so an empty
dtd was supplied when the transform was made so teh dtd defaults did not
happen.

David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Current Thread