W3C home > Mailing lists > Public > xml-names-issues@w3.org > July to September 1998

Re: Error Handling

From: James Clark <jjc@jclark.com>
Date: Mon, 17 Aug 1998 11:30:51 +0700
Message-ID: <35D7B1FB.4EFDC64A@jclark.com>
To: David Brownell <db@Eng.Sun.COM>
CC: xml-names-issues@w3.org
David Brownell wrote:
> 
> This doesn't address the questions about how the errors should be
> handled, note!

Hey, I don't have all the answers :-)
 
> James Clark wrote:
> >
> > David Brownell wrote:
> >
> > >         That is, does this spec increase parsing costs by requiring such
> > >         state to be stacked even in event-based parsers which currently
> > >         don't need to record such state?
> >
> > They already have to maintain a stack of open element type names.
> 
> That one can be realistically merged with the call stack, and since
> it's used only to recognize end tags it's not needed outside of the
> block of code handling that element.  Cost:  normally a pointer on
> the stack, and often no dynamic memory allocations.

It depends whether you have a "pull" or a "push" parser interface.  If
you have a "push" interface (like expat), where the client passes input
to the parser by making calls on the parser, you have to have a stack.

> A stack of open naming prefix bindings is different.  It's needed
> outside that block of code, and so needs a more complex interface.
> Since each new element can introduce an arbitrary number of new
> bindings, it's not got the inherent efficiency of the fixed size
> (one string pointer) stack member.  It's also got to support a
> special "default" binding.

Well you could represent it a list of prefix/binding pairs plus a
pointer to the previous pair, put each list member on the call stack,
pass the list head as a parameter and make a recursive call for each
binding.

Also checking for attribute uniqueness and doing attribute defaulting
require relatively complex interfaces already.  I doubt namespace
processing is much more expensive than attribute defaulting.

> So I think it's fair to say that if this "must" be done during a
> parsing stage, it clearly increases parsing costs.

Obviously namespace processing increases parsing cost, but I still don't
think it's a kind processing that's dramatically more expensive than the
kinds of processing that parsers already do.

James
Received on Monday, 17 August 1998 00:54:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:43:30 UTC