[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL: Re: Working
- To: Mark Dunnett <mdunnett@citilink.com>
- Subject: SEUL: Re: Working
- From: Roger Dingledine <arma@mit.edu>
- Date: Fri, 11 Sep 1998 14:16:17 EDT
- cc: seul-pub-www@seul.org
- In-reply-to: Your message of "Thu, 10 Sep 1998 13:10:46 CDT." <Pine.GSO.3.96.980910130653.24888A-100000@homebase>
- Resent-Date: Fri, 11 Sep 1998 14:16:16 -0400
- Resent-from: omega@seul.org
- Resent-Message-Id: <199809111816.OAA23925@cran.mit.edu>
- Resent-Sender: omega@seul.org
- Resent-to: omega@omegacs.net
- Sender: owner-seul-pub-www@seul.org
[I cc'ed this to seul-pub-www, to keep people informed of what
people are working on. Hope nobody minds.]
In message <Pine.GSO.3.96.980910130653.24888A-100000@homebase>, mdunnett@citilink.com writes:
>There is a parser at ActiveState called XML::Parser. Pretty cool, does
>basically the same thing SDOC is doing with XML. It may be possible to
>take this parser and make some small additions to it, giving us current
>SDOC functionality along with XML. I'm playing around with it now. The
>parser can be found at:
>http://www.activestate.com/ActivePerl/download.htm
>In the meantime I will continue with SDOC.
>
>Mark
Ok...so I checked out activestate, and the activeperl program. It
appears to be "yet another" port of perl to win32. There might be
an xml::parser in there that's completely separate, but activestate
is distributed as a win32 executable, so....
Also, I'm unconvinced that their license is satisfactory. It allows
me to use it for free (gratis), but I have no permission to modify and
freely redistribute.
sdoc, on the other hand, is truly portable because it uses simple
aspects of perl that are included in all perls, on all platforms.
sdoc is a hell of a lot smaller, and under better licensing (fully
GPL).
But apart from that, thanks for noticing activestate and pointing it
out to me. I'm very curious what the differences are between sdoc and
their xml parser. My goal with sdoc is to implement a good parser, and
once we're done notice that hey, it supports xml too, because it's
"just that good". :) I'm suspicious of something that is built specifically
with xml as its goal, since it might not as flexible as it should be.
On the other hand, I might be totally confused about how easy it is to
be xml-compliant. My goal is to make it so that we can simply assimilate
what xml documents need by making more handlers for them, and treating them
as normal html-style tags. Rather than saying "every xml document needs
to have <?xml> and <!doctype> tags", we can have a handler for <?xml>, and
if it finds a tag like that, then it assumes it's an xml-compliant document
and deals from there. Anyway, that seems much more intuitive to me.
Comments?
--Roger