XML parser timeline and complexity

Fairlight fairlite at fairlite.com
Sat Feb 11 13:54:50 PST 2006


With neither thought nor caution, Bill Campbell blurted:
> 
> It sounds like you're trying to reinvent expat, SAX and DOM for FilePro :-).

Expat and XML::Parser, more or less.  I mean, not literally, but same
tasks.  More the Expat part than the other module, really, as the whole
problem with XML::Parser and why one can't use it as a generic parser in
the context of fP and assigning things to fields in a database is that with
every schema or dtd change, the relationships change--and so would the code
for the event handlers in XML::Parser.

> Tools like the python xmlrpc libraries hide all the XML from the
> programmer, permitting very simple function calls.  The SAX and DOM
> libraries make it reasonably easy to read/write XML documents, and there
> are both verifying and non-verifying parsers that are fairly easy to use.

After several attempts in which I couldn't figure for the life of me how to
get XML::Parser to do more than spit out the same XML file it got inbound,
it finally "clicked" a few years ago, and I figured it out.  Dreadfully
simple, but it just isn't flexible enough to be generic at the user level.

> Writing external XML import/export routines that are calleable from FilePro
> would seem a much more reasonable approach.

If you're saying that one could write an XML->import (say, CSV) type
engine, I suppose one could--except you can easily break the CSV type
syntax with perfectly valid data in XML.  That's one reason XML is a lot
stronger--you can do more with it.

The whole problem with doing XML is that you need to not just parse it, but
give the user the ability to "map" the schema or dtd onto tables/fields.
Which pretty much may involve rewriting the schema -again- in one form
or another.  So now I'm thinking maybe it -is- wiser to dump testing the
document structure via the official means and just parse it syntactically
and store it according to defined relationships, as I first thought to
do.  If something is malformed, do the best one can with it or generate an
error.

Except that's horribly sloppy, and I don't like the idea of being sloppy
about it at all.

Too bad I likely won't be able to wait a year for them to finish theirs.

Ugh, even worse thought:  You can mix namespaces inside XML documents.
It's done all the time in SOAP.  There's yet -another- complication.

Okay, my brain hurts again--and I -just- got up!  :-/

mark->


More information about the Filepro-list mailing list