[XML-SIG] Re: [4suite] Disentangling StylesheetReader from Ft.Lib

[Martin v. Loewis]

>> It seems to me that all StylesheetReader does is to
>> create a DOM tree, except that it creates StylesheetElement nodes
>> where a normal DOM build would create Element nodes.

> Wow.  I'd count this a huge oversimplification.  The Stylesheet reader
> does a great deal that most readers needn't worry about, as I'd think
> would be obvious from a glance at te code.

I'd like to discuss specific aspects, then. Looking at the current
public CVS, I see:

fromStream: duplicates ReaderMixin.fromStream, then adds call to
            sheet.setup(), and some error handling

initParser: duplicates PyExpatReader.initParser. It uses
            Utf8OnlyHandler sometimes, but I could not find that class.

_completeTextNode: creates LiteralText instead of Text nodes. Also does
            not deal with top_node, but I'm not sure whether this is on
            purpose

_initializeSheet: has no equivalent elsewhere
_handleExtUris:   has no equivalent elsewhere

processingInstruction: Does *not* create PI nodes
comment:               Likewise

startElement: great similarities with Handler.startElement. The significant
              differences seem to be:
              - creates element nodes based on g_mappings[nsuri][localname],
                extension tables, or creates LiteralElement
              - processes xsl:include somehow (?)
              - passes attributes through _handleExtUris for xsl:stylesheet

endElement: great overload with Handler.endElement; I could not tell
            whether differences are on purpose or by mistake

characters: does not deal with _includeDepth and force8Bit (again, this
            might be by mistake)

Did I miss aspects of the functionality relevant to proper operation
of the StylesheetReader?

So all in all, it still seems to me that the essential difference is
what nodes are created; the control logic and parsing data structures
seem to be duplicates of the code found in the handler.

That, in turn, suggests that using a standard DOM builder with a
different DOM implementation would achieve the same effect.

Regards,
Martin