[XML-SIG] Re: [4suite] Disentangling StylesheetReader from Ft.Lib
Martin v. Loewis
Mon, 14 May 2001 09:26:46 +0200
>> 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
_initializeSheet: has no equivalent elsewhere
_handleExtUris: has no equivalent elsewhere
processingInstruction: Does *not* create PI nodes
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.