Need help on File parsing

R

Rui Maciel

Nobody said:
You make it sound as if it's a significant issue. Once you have the
lexer, XML is trivial to parse. There are no shift-reduce or
reduce-reduce conflicts, because every construct begins with a token
which is unique to that construct.

Writing your own parser is not a significant issue. That's why people opt
for the SAX approach. And you only stumble on shift-reduce/reduce-reduce
conflicts if you are trying to develop a parser for a language which
suffers from ambiguity issues, which doesn't really apply to XML or any
language based on XML.

The point is that you don't have to code dedicated utilities for common
tasks, as you can just use xslt, xquery, etc.

The point is that if a programmer tries to avoid developing a parser for
his language because he believes it takes too much work, adopting layers
of 3rd party libraries won't save him any work in the end, nor will it
make his life any easier.

Probably the only benefit a programmer gets from insisting in using those
3rd party libraries is that he can pad his resume with lots of buzzwords,
although in the end the only thing they demonstrate is that that
programmer invests his time implementing bloated tools and forcing the
wrong solutions onto jobs which otherwise would be considerably simpler
and more efficient.

You don't have to write
bindings for a variety of languages

It's irrelevant. Once you know how to develop a parser in a given
language you are able to develop a parser in any language you know.

, as every common language already
has XML parsers (and more, e.g. tools which will generate class
definitions from a DTD or vice-versa).

As I've stated before, adopting a 3rd party library that handles XML
doesn't mean you avoided the need to develop your parser. You are still
forced to develop a parser, whether to parse a tree structure which is
assembled by the 3rd party library or to implement a working parser from
the glorified lexer which has been provided.

Adding to this, when someone mindlessly adopts a 3rd party library to
process XML documents and does so not because he believes XML is the right
tool for the job but simply because the 3rd party library is there and he
doesn't know any better, that person tends to be forced to shoe-horn XML
into an application which it isn't suited. This is one of the reasons we
tend to see XML being forced into uses that clearly it isn't the best tool
for the job. Or even adequate. It's one of those examples of "if all you
have is a hammer, everything looks like a nail".

In many cases, the only valid reason for /not/ using XML is efficiency
(I don't consider the vendor lock-in which proprietary formats offer to
be a "valid" reason).

There are plenty of reasons why XML is not the right tool for the job, and
thanks to the "but there is an API for that" mentality, there are plenty
of examples that demonstrate how XML is being forced into jobs it isn't
fit to do. For example, it doesn't make any sense to rely on XML to
encode any data structure beyond trees. And some people insist on
pounding the XML hammer on that nail.


Rui Maciel
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top