[ Mostly off-topic for openjade-devel, but I'm CCing since I ]
[ mention OpenJade/OpenSP <URL:http://openjade.sourceforge.net/> ]
Nick Kew wrote:
>On Tue, 6 Mar 2001, Terje Bless wrote:
>
>>Could we parhaps prevail on you to do some hacking on
>>the-SP-based-SGML-parser-of-the-moment (SP/lq-nsgmls/onsgmls)
>>to fix problems/add features at need?
>
>I'm already doing that (see my other post), though I have not (yet) found
>time to relate my mods to the OpenSP project. If there are requirements
>for the validator, I'll be happy to look at them - time permitting.
Well, time is obviously the great limiting factor -- as Gerald will be the
first to attest :-) -- but right now, _no_ issues get dealt with if they
live in C++-land (i.e. in the SGML Parser du jour) so even if you don't
have time for several months it'll still be an infinite improvement. :-)
Actually, the biggest help, if you or Michael can find the time, would
probably be contributing to the OpenJade project in the OpenSP area. I'm a
bit fuzzy on what Gerald had to say about it, but AFAICT, OpenSP is the
only sane choice for the future. If it had your Redirect patch applied I'd
have started pushing for adopting that as soon as OpenSP 1.5 is final (it's
in pre5 right now).
OpenSP has some nice features -- not the least of which is Autoconf
support! -- and is actively maintained, but they seem a bit short on
developers ATM. If you could find some time to help them out I'm sure they
would appreciate it as much as I would.
A couple of specifics off the top of my head:
* Output redirection.
-- Right now we're doing some gnarly shell redirects to get output where
we want it. Being able to use command line switches to put it in a
file would be much preferable.
* Specify all environment stuff on the command line.
-- Right now we're setting SP_ENCODING et al in the environment; this
is messy and falls apart in mod_perl land.
* Ability to say: "use this SGML Declaration and this DTD".
-- SGML Open Catalogs are fine and dandy an all, but for some things it
would be much less painfull to say "use this" on the command line.
* Blue Sky: A Perl (XS) Module Interface
-- Calling an external binary is *messy* and HTML::Parser doesn't do
what we need. A SGML::Parser module that could be called as SP is
now would cure a whole host of headaches and enable a gazillion new
features.
* Blue Sky: Configurable Error Format
-- The error messages are an exception for most SGML Processors, but
for the Validator they are the norm. Being able to play tricks with
the format and fields of the error output would be usefull. Reporting
context a bonus!
The HTTP Host-header and Redirect support are other examples of issues that
need to be handled at the SGML Parser level (because there is just simply
*no* way I'm working around them from Perl-land!).
>But how do you actually operate? Major collaborative projects work by
>mailinglist, but *this* list isn't like that
Well, in theory, this list is it. However, it's traditionally been more
focussed on end-user issues then developer issues. Presumably this has been
because the number of developers has been exactly _one_, with a few people
sending in patches on this list. Lately I've been talking to Gerald on IRC
and coordinating work that way. I dunno how he'd want to organize things if
more people put their hands in (wanna chip in here Ger?).
Specifically for the SGML Parser aspects, it can probably be coordinated
here on w-v or in private email. Maintaining W3C-specific diffs isn't a
good option so working within the OpenJade infrastructure and add changes
at the source would probably be a good idea as far as our needs are
compatible with theirs. At the moment, an SP-compatible SGML Parser is an
external prerequisite to the W3C Validator; no code is kept in CVS. I at
least would like to keep it that way if at all possible.
Anyways, since I now have two vict^H^H^Holunteers to deal with C++ stuff,
I'll be sure to give y'all a holler whenever something C++ comes up. :-)
BTW, Michael, how's your Python these days?