[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Roll-Your-Own Parsers (was: Re: What Clean Specs Achieve)

• From: hpyle@a...
• To: Tyler Baker <tyler@i...>
• Date: Wed, 10 Feb 1999 11:17:24 +0000

Tyler Baker <tyler@i...> wrote,

> > (roddey@u...)
> > see if that file seems to correspend to the spec and fix their code to
> > handle if so. That is far easier than trying to prove that every method
in
> > your code meets the spec (though its obviously not the optimum thing to
> > do.)
> Yah, generally if you control how your data is created, you can whip up a
decent parser to
> meet your needs.  Also, if you don't check for a lot of the obscure
errors that may pop up you
> can save yourself a ton of time in processing overhead.  ...
> But if you just want to have some basic XML capabilities for your
> organization and don't want to deal with using other people's codebases,
XML is not too much
> of a beast (understanding the spec takes longer than writing the code at
first).
>
> > Am I being too cynical here? Maybe so. But, I just don't think that an
> > 'average' developer could write an XML processor that is complete,
> > expandable, maintainable, and speedy, if all he/she had to work with
was
> > the raw XML spec...
> Very true.  I fell into this trap when people on this list were talking
about how an average
> university CS student could whip one up in a week.  At first I said
"geese this is easy" but
> when I started caring about performance and being able to detect some of
the very obscure
> errors to be 100% compliant with the draft, I found myself going insane
on doing a lot more

Totally agree.  There will always be a tradeoff between code size,
performance and conformance to the spec.  We have taken the same approach:
for XML which might go outside our environment or some in from outside, we
use a heavyweight parser with full validation.  But where it's "behind the
covers" we use a homegrown (tiny, nonconformant) parser and just check the
structures a few times during design, with a validating parser.

> You can thank the many people here who have provided open-source parsers
to work from

Ditto.

-Hugh
hpyle@a...




xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• Follow-Ups:
  • Re: Roll-Your-Own Parsers (was: Re: What Clean Specs Achieve)
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: RE: "Namespaces in XML" idea?
• Next by Date: re: RDF, Namespaces, and Versioning?
• Previous by thread: ANN: IBM XML Parser for Java (XML4J) v2.0.0
• Next by thread: Re: Roll-Your-Own Parsers (was: Re: What Clean Specs Achieve)
• Index(es):
  • Date
  • Thread