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

[Uche Ogbuji]

Mike Olson wrote:
> 
> "Martin v. Loewis" wrote:
> >
> > I've tried to update my 4XSLT port to use the 4Suite 0.11 code base,
> > only to discover that the StyleseetReader class is now much stronger
> > connected to Ft.Lib than before, in particular to classes from
> > pDomletteReader, and their specific instance attributes.
> 
> I was just in there as well and quite suprised how complex the code has
> become.  I thought of doing some work on it but figured, it ain't
> broke.....

This is a false impression.  The code is actually quite simpler than it
was before.  In the past, we had the code for mapping prefixes to NSUris
releated in pDomlette/PyExpat, pDomlette/SAX and StylesheetReader.  Now
it's in a single place.  There are many other places where code is now
shared where before it was duplicated.

It certainly needs a lot of polish still: the main problem is that all
the reader systems have evolved separately, and mix-in based
implementation merging is probbaly the best solution.

> My thoughts were that the implementation should be able to hadle it,
> then there would be on reader.  all of the code in the Stylesheet Reader
> would be handled in StylesheetDocument.createElement, or atleast the
> marority of it.  I haven't looked too closely to see if this is 100%
> feasible thought.

I don't favor this.  I think tight coupling with the parse mechanism is
important for efficiency.  It would be better to hav e a separate
fall-back Stylesheet Reader that did things throught DOM interface only
(althought I'm not sure what this would buy us since the same amount of
work would then need to be done in the DOM implementation).

> > I took the approach of providing alternative base classes to the ones
> > provided by pDomlette, but that soon became a desaster since none of
> > the minidom/pulldom classes bear any relationship to how the
> > PyExpatReader and Handler classes work.
> 
> Is pDomlette the only import from Ft.Lib?  If so, why not move pDomlette
> into xml.utils?  Better yet, let's merge pDomlette and minidom so there
> is only one domlette.  pDomlette has greatly out grown its original
> purpose so I have not problems with moving it into XML-Sig.

I disagree with the idea of merging pDomlette and minidom, but I have no
problem mocing pDomlette to xml.utils.

> > I'd still like pursue my attempt of integrating 4XSLT to work without
> > Ft.Lib, and pDomlette in particular, but I'd need some advise here.  I
> > feel that I miss some grand picture in all these classes, and how they
> > are connected. It seems that the authors of the code lose track, too,
> > with code duplication all over the place.
> 
> I agree.  There was a lot of redundant code when I looked into it last.
> I think there should be one xml-sig "reader" that works off a
> DOMImplementation to create actual instances.

Disagree.  See above.  Things can be parameterized more usign DIMImp,
but not at the parser interface level.

> Some things to note are that this would slow things down.  One big speed
> increase the pDomlette gives us by having its own reader is that it can create
> elements directly and not have to use the createElementNS interface.  The problem
> with the interface is that we have to do a "prefix + ':' + localName"
> just to satisfy the interface (and then the function itself does a
> sting.split(qname,':').  Not really a time consuming process, but when
> you call it 10000 it adds up.

There's more to it than just this.  There is a lot about the DOM factory
interfaces that is very inefficient.


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