[
Lists Home |
Date Index |
Thread Index
]
John,
I've never directly been involved at parsing xml in this
way. Don't mind using XPath and perl, but most of the
stuff that I do is with custom libraries in delphi
of all languages (to do with gui writing mainly)
Starting of thinking there might be some merit to the
binary xml as some spare parts pricelists, when they
get to 40,000 items, start to slow things down a bit
to load into memory at one time.
Most of the time I just tweak something here or there
and it comes good again.
But I can see some advantages in binary xml. Searching
through documents for tags in text is not that efficient
compared to running down a binary linked list.
Anybody that really understands parsing theory I respect
like a god. Some peoples brains are just wired that
way. Not mine. I still would would put money on the
yacc mathematical expression generating code as being
black magic. There's no logical way that sort of stuff
can work.
To me, the amount of computer interaction at the
moment in the real world is very minimal. One connection
at a time per trading partner then turn off. Our
textbooks all say "TCP/IP connections are resource
intensive". So what do we do, get out of our browser
and get onto our p2p download client and have some
nice feelings of multiple connections.
The accounting systems no matter what the brochures
say are still mainly souped up printing presses with
a choice of squirt the ink or burn it in to the paper
with lasers.
and in businesses at the small and medium sized
level, they haven't even heard of xml. Wouldn't even
have the slightest idea what it is.
I think there is a rosy future ahead....
Quoting John Cowan <jcowan@reutershealth.com>:
> david.lyon@computergrid.net scripsit:
> > Paul,
> >
> > Interesting. at least in perl it's a respectable language.
> >
> > Don't seem to mind the idea of parsing stuff in perl.
> >
> > but this:
> >
> > http://www.linuxgazette.com/issue87/ramankutty.html
> >
> > that looks like a lake of fire...
>
> LR(1) parsing is a very standard technique, but it has problems, notably that
> changes to the grammar *here* may cause unexpected yacc-compile-time errors
> *there*. PEG parsers are much superior, though they require more space
> (potentially O(N) space where N is the length of the input, though not
> typically): see http://www.cs.nyu.edu/rgrimm/xtc/rats.html#overview .
>
> --
> "You know, you haven't stopped talking John Cowan
> since I came here. You must have been http://www.reutershealth.com
> vaccinated with a phonograph needle." jcowan@reutershealth.com
> --Rufus T. Firefly http://www.ccil.org/~cowan
>
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
|
