xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arved Sandstrom <Arved...@chebucto.ns.ca>
Subject Re: parser-next-gen goals, plan, and requirements
Date Fri, 14 Jul 2000 14:11:08 GMT
At 02:42 PM 7/13/00 +0200, Stefano Mazzocchi wrote:
>Edwin Goei wrote:
>> 
>> "Tim Bray" <tbray@textuality.com> writes:
>> 
>> > Wild-eyed suggestion: why not look into adopting James Clark's XT?  It's
>> > a pretty #!%@^#@ good parser IMHO.  Also it's from neither IBM or Sun :)
>> 
>> Yup, I think it's worth looking at the internals of XP also (you probably
>> meant XP), I just haven't done it yet.  Maybe other people who have can
>> comment.  It looks like an older parser which hasn't been updated.  There's
>> also the parser that you wrote, Lark, which you might want to comment on.
>> 
>> The other parser I have looked at is Aelfred2 which is a current SAX2 based
>> parser.  I think its easier to understand than the current Xerces code, but
>> it also does less.  But maybe we're still in the requirements stage right
>> now and these are more implementation details.
>
>+1 on making 
>
> Xerces2 = Xerces1 ideas + Crimson ideas + XP ideas
>
>I'm sure James Clark has _lots_ of design decisions to share on parsers.

If we are trying to capture ideas, let's look at _all_ the parsers, where 
the source is available and licenses permit.

We're not just in Java land here; we've got Xerces-C and Xerces-Perl and 
they can't be shuffled off.

There's stuff that microparsers like nanoxml can contribute to the 
discussion. Python XML parsers (and there is more than one) are quite good. 
If we are talking James Clark, let's not forget expat; this is a very good 
parser and represents the core of the Perl XML processing family.

Correct me if I'm wrong but we are still capturing requirements. Maybe 90% 
of the folks here plan to actually write Java as a result, but before we get 
to detailed design I wouldn't expect to see a single-minded focus on Java.

I think there is potential here for making this project best-of-breed when 
it comes to showing that open-source can do process. I think it would be 
awesome if "Xerces2" generated docs for conops, requirements, and design 
that allow folks down the road to step in and write a parser in Eiffel, for 
example (this is my plug for Eiffel, unabashedly... :-)), or in Python, or 
whatever.

Just my CAN $0.02 worth.

Arved Sandstrom

Senior Developer
e-plicity.com (www.e-plicity.com)
Halifax, Nova Scotia
"B2B Wireless in Canada's Ocean Playground"


Mime
View raw message