Scott, Joe, David --
Is it just me (highly possible in this case) or are there some real
issues with namespace processing in XalanJ2. I have been very confused
over this, partly due to my own lack of in-depth understanding but I
think I grok the issues now. Here are the questions/observations that I
have.
1. On the serializing of the transformation output, who is responsible
for determining when to emit namespace declarations in the serialized
output? Is it ResultTreeHandler or is it SerializerToXML and its
offspring? It seems like this is currently being done in
ResultTreeHandler but I think it belongs in SerializerToXML. That way,
SerializerToXML could be used as a proper serializer for any XML
output. I realize that it's not supposed to be a general purpose
serializer for use by other applications but it would be nice if that
were the case, at least with some restrictions. I view
ResultTreeHandler as just a bottlenecker to handle things like
accumulating attributes before calling the real content handler and
providing the tooling interfaces.
2. It seems like we're handling exclude-result-prefixes by referencing
the prefixes (whose URI bindings can change throughout the stylesheet)
rather than by referencing rhe URIs in scope at the time the
exclude-result-prefixes attribute appears, as I think is required by the
Recommendation.
3. We're not properly handling namespace nodes on the source,
stylesheet, or result trees. See
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2650
Namespace nodes cannot be shared between element parents.
I know that Joe did some work with NamespaceSupport2 but I'm not sure if
that was prompted by performance or compliance or what. I suspect if we
clean up the compliance, performance will also improve. In some traces,
it seems like things are being done repetitively in multiple places but
that is just my impression.
Again, I may be way off base here since I've been combining debugging
with learning both XalanJ2 and XSLT namespace processing. Any thoughts?
Gary
