Re: Clarification on xsl:attribute requested

"Rick Jelliffe" <[email protected]>
Newsgroups gmane.org.w3c.xsl-editors
Message-ID <[email protected]>



From: "Kay, Michael" <[email protected]>

> Firsly, I assume I should read "Xalan" for "Xerces" throughout.

Good catch. Actually our report was "JAXP 1.2 from the summer '02 XML 
Pack download from Sun. It's based on Xalan-j 2.3.1_01 "  Far too many X things.

> In XSLT 2.0 we've added xsl:namespace as a proper solution of the problem.

Excellent.
 
> I'm not sure if the above is pertinent to your problem with Xalan: are you
> looking at the serialized output, or at the result tree?

Serialized output.

> XSLT 2.0 introduces the notion of namespace fixup, which makes it clear that
> a namespace node is indeed added to the result tree. I think that
> introducing this concept to XSLT 1.0 is too big a change to do by means of
> an erratum.

But MSXML, XT, Xalan4C 1.0, Xalan4J 2.0, Oracle, SAXON, infoteria, and
several others support work this way already (otherwise they would fail) So I don't believe it is a big change: it is common practise. 

> XSLT 1.0, and 2.0, are both quite explicit that when you create elements and
> attributes on the result tree, there is no guarantee what prefix you will
> get. We recently considered whether we should add a recommendation on the
> prefix to be used in the case of xsl:namespace-alias, and the group was
> firmly against it. So I think it's unlikely the group would want to accept
> this proposed change.
 
Just to clarify: 

1) So you are saying that there are XSLT 1.0 transformation possible
that result in an invalid infoset?  So if I do
  <xsl:attribute name="xxx:zzz" namespace="blahblah" />
that an implementaiton may serialize the result without a namespace
declaration?   (That is the thing I think is a bug, that should be clarified.)

2) You think the WG would be against even even a recommendation of
best practise that implementations should attempt to use existing
prefixes rather than generating their own, where possible.

Cheers
Rick Jelliffe
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.