[XML-SIG] qp_api and the DOM

[Paul Prescod]

Greg's absence gave me a little bit of time to catch up on work (of course
not enough :) 

I think that what Greg and I are trying to accomplish may be so divergent
that trying to unify the efforts may be a waste of time. Here's how I
interpret the differences:

I think that Greg wants to make a *module* for his own use and the use of
others with his concerns.

I want to make an *API* which explicitly permits multiple, interoperable
implementations -- including wrappers over existing C libraries like
xml4c2 and Java libraries.

I think that Greg's ordering of priorities is performance, simplicity,
familiarity, completeness and interoperability. It seems to me that a
module will meet this ordering of priorities better than a standardized
API.

My ordering is completeness, interoperability, familiarity, simplicity,
and performance. It is because I rank interoperability so highly that I
want to make an API instead of a module.

I rank completeness highly because I think that my API should be
applicable to as wide a range of software as possible. Greg doesn't mind
restricting his API to just a "data-centric" subset.

I think that Greg wants his library to be part of the Python XML-SIG's
distribution, I'm okay with that. I think that at least one implementation
of the Python DOM API should be part of that distribution also.

I also think that some library conforming to the DOM API should eventually
be part of the Python standard library -- perhaps partially coded in C. A
DOM implementation is appropriate for the Python standard library because
it is designed to be general and familiar.

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

Diplomatic term: "We had a frank exchange of views."
Translation: Negotiations stopped just short of shouting and
             table-banging.
(Brills Content, Apr. 1999)