Re: [Perlsgml-dev] [FYI/RFC] SGML::Parser::OpenSP and SGML::Parser...

[Earl Hood]

On April 7, 2003 at 10:14, Terje Bless wrote:

> Licensing is not entirely clear either; one school of thought suggests this
> would have to be under the W3C License (GPL-compatible), but that probably
> isn't necessary. For ease of use, the Perl terms (e.g. GPL+Artistic) is
> probably the sanest option.

Anything that is compatible with GPL is okay.  My only concern is
that Savannah is hosted by GNU and I do not want to violate their
licensing requirements of projects hosted at the site.  Technically,
the Artistic license is not GPL compatible, but Perl can be distributed
under the GPL or Artistic (user choice).  Therefore, when stating
that code can be distributed under the same licensing of Perl, you
get GPL compatibility indirectly.

> Well, I don't think it would be appropriate to call my code SGML::Parser --
> at least in the near future -- as the original is far more functional.
> That's why I've been thinking about making a "SGML::Parser" that is a
> proxy/common frontend module with pluggable backends. That would let your
> SGML::Parser be SGML::Parser::Perl and be the default implementation, and
> SGML::Parser::OpenSP be an option.

I think a good initial step is to design what the public API of
SGML::Parser should be.  I see SGML::Parser as something at the event
level (i.e. SAX-like) vs at the object level (i.e. DOM-like).  The
API can be designed independent of what the back-end implementation is.
Once done, we have a stub of what back-end implementations must support.

We could also provide a way for back-ends to only implement parts of
the API so a user could query which API methods are supported for a
given API.  I guess what could be developed is a DBI-like model for
SGML parsers.

BTW, Java has a similiar model with XML parsers they introduced in
JDK 1.4.  The JDK defined a generic API, but different backends could
be hooked in.

> I will likely have to do the same for the XML functionality in the
> application; I need to do both SGML and XML, and while OpenSP does XML it
> has limited support. e.g. I will probably have to make an
> XML::Parser::OpenSP -- along with XML::Parser::Xerces and
> XML::Parser::LibXML -- to plug into a generic XML::Parser frontend (not
> called XML::Parser obviously, but analogous to the postulated SGML::Parser
> frontend module).

Since a long term goal is to provide multiple backends, I believe hosting
this work separate from OpenSP is justified.

Side note, I believe someone years ago had written some modules that had
bindings to SP.  Searching CPAN, I think the following URL is definitely
worth a look, <http://search.cpan.org/author/KMACLEOD/>.

--ewh