again many thanks for your most careful consideration of the problem. I understand well that the issue has a very low priority and cannot occupy you any more right now.
Therefore please regard the following remark as meant "for future use" strictly.
I have come to the conclusion that bug #5857 is a false alarm, that there is no real problem associated with the status quo of the spec and that therefore the Saxon implementation should return to a rigorous implementation of "5.7.1 Constructing complex content", item 12. Why?
The resemblance of a problem arises from the implicit assumption that the application of inherit-namespaces="no" is something like an extra action the stylesheet author should not be required to do. But this is wrong, at least if one regards the difference between relying on a default value or explicitly setting an alternative value as irrelevant. Behind this external, purely representational aspect there is the fact of an (implicit) "copy namespaces mode", corresponding to the explicit copy namespaces mode of XQuery. The rules are straightforward:
(a) the combination preserve/no-inherit warrants the faithful reconstruction of the in-scope namespaces of the source node
(b) the combination preserve/inherit means the union of preserved and inherited namespace nodes, thus implies the possibility of additional namespace nodes
(a) the preserve/no-preserve component is fixed to "preserve", contrary to XQuery.
(b) the inherit/no-inherit component defaults to "inherit" and can be locally reset to "no-inherit" (via "inherit-namespaces='no'")
If one wants the in-scope namespace nodes of an element to be restricted to a faithful reconstruction of the in-scope namespace nodes of the source node, it is obviously the mode "no-inherit, preserve" what is required. The fact that this does not coincide with a default rule is irrelevant. The inconvenience could, however, be very effectively attenuated by the introduction of a new xslt attribute, "inherit-namespaces-default" to be set on the xsl:stylesheet or xsl:transform element, or something along those lines. (The default of the default would of course be "no", preserving backwards compatibility).
With kind regards,
>>> You wrote:
I think there are actually conflicting requirements. The use case cited
in the original bug report seems clear enough: the user clearly wants an
xmlns="" in the result tree and isn't getting one. Your use case is the
opposite - you are getting an xmlns="" where you don't want one. I'm not
optimistic that it will be possible to come up with a set of rules that
doesn't lead to surprises for someone.