Gary L Peskin <[EMAIL PROTECTED]> wrote:
> 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 don't disagree for the most part. Also, startPrefix/endPrefix should be
working properly in SerializerToXML. On the other hand, I *think* the
ResultTreeHandler may still have to track namespaces (I could be wrong), so
it would be a drag to have to track them in both the ResultTreeHandler AND
the SerializerToXML. I believe that was my thinking when I wrote them,
though, at this point, I can't be sure.
XSLTC folks, take note, as I think our intention is that we converge the
serialization stuff between XSLTC and interpretive Xalan. Opinions?
> I realize that it's not supposed to be a general purpose
> serializer for use by other applications
Actually, I don't think this statement is true as such. It would be nice
to generalize the serializer if possible, and should be part of the design
goals. Note that the JAXP 1.1 identity transform is a generic
serialization, and, when it goes through a TransformerHandler, should
handle startPrefix, redundent namespace decls, etc.
> I view
> ResultTreeHandler as just a bottlenecker to handle things like
> accumulating attributes before calling the real content handler and
> providing the tooling interfaces.
Yep.
> 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.
I *think* we're handling these right, though I could be wrong (I'm saying
this off the top of my head, without thinking deeply or looking at the spec
and our code). You should post a separate note about this with an example
so we can discuss it in detail, and also look at what other processors do.
> 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.
Yep, this is a well known bug, which I'm not sure I'm inclined to fix. The
DTM makes this really hard to fix unless we're willing to always replicate
the namespace nodes on every element from the start, which I'm not (if this
is to be supported, it has to be done lazely). If you have a good proposal
on how to implement this in the DTM, I would be very happy. [the problem
is, we can't insert nodes on the fly into the DTM handle space...] On the
other hand, note that the definition of namespace identity and parentage is
likely to change in XSLT/XPath 2.0.
> I know that Joe did some work with NamespaceSupport2 but I'm not sure if
> that was prompted by performance or compliance or what.
It was prompted only by performance issues. The functionality of
NamespaceSupport2 vs NamespaceSupport in SAX2 did not change, though he
also did some performance improvement in its use in the ResultTreeHandler.
> In some traces,
> it seems like things are being done repetitively in multiple places but
> that is just my impression.
It's my impression too, but I've not been able to nail it down. The
problem is, when I'm doing this stuff in the context of a hundred (or
thousand) other issues, I'm happy just to get it working (not to make
excuses...). Certainly it feels a bit too catch-all and clunky. I'm sure
you can improve on it.
> Again, I may be way off base here since I've been combining debugging
> with learning both XalanJ2 and XSLT namespace processing. Any thoughts?
I'm glad to have you looking at this.
BTW, while you're looking at namespaces & ContentHandlers, you might have a
look at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2877. This is a
long outstanding bug that I'm not sure how to fix because of the need of
XSLT to know about prefixes, which I don't see how we can do without the
qname.
Also, regarding your "Fix for bugzilla 3060 (
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3060)" today, Joe was
noting today that maybe my design for m_prefixMappings, i.e. even/odd
mapping, sucks (he was more diplomatic), that it is perhaps too complex and
not worth the cost of economy. Could be. Also, the design for
SAX2DTM#m_dataOrQName is completely incomprehensible and bug prone, but
here I think it might be worth the cost of economy. (See around line 1715
of SAX2DTM). Anyway, your wise design input to these issues are, as
always, welcome.
-scott
