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

[Mike Olson]

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

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


> 
> So my question is: Is all this complexity really necessary? Would it
> be possible to simplify things by breaking down processing in multiple
> processing steps? 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. If this is really
> all it does, I could propose some dramatic code reduction.

It also does validation, processing of include and import elements,
namespace aliasing, extension element processing, and more.

Though like I said, I think this could be handeled in a createElementNS
of a StylesheetDocument class.


Mike

> 
> Any proposals are welcome.
> 
> Regards,
> Martin
> 
> _______________________________________________
> 4suite mailing list
> 4suite@lists.fourthought.com
> http://lists.fourthought.com/mailman/listinfo/4suite

-- 
Mike Olson				 Principal Consultant
mike.olson@fourthought.com               (303)583-9900 x 102
Fourthought, Inc.                         http://Fourthought.com 
Software-engineering, knowledge-management, XML, CORBA, Linux, Python