[XML-SIG] qp_api and the DOM
Mon, 03 May 1999 08:31:54 -0500
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
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
Diplomatic term: "We had a frank exchange of views."
Translation: Negotiations stopped just short of shouting and
(Brills Content, Apr. 1999)