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

[Uche Ogbuji]

> >> 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.

There is a lot of state that the StylesheetReader manages that other readers 
don't.

This would be very cumbersome to shoe-horn into a standard DOM reader.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com 
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python