[XML-SIG] qp_api and the DOM

Greg Stein gstein@lyra.org
Tue, 04 May 1999 03:50:32 -0700


I generally dislike responses like the one I'm about to make, but I'm
leaving town again for a few days :-), so...

--> yes, absolutely, right-on-the-money, excellent.

I believe that I was trying to state some of this in the dichotomy I
proposed, but (as you pointed out) that was flawed. IMO, you've analyzed
it much better.

More on Friday or so...

thx!
-g

Paul Prescod wrote:
> 
> 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.

--
Greg Stein, http://www.lyra.org/