Re: Error Handling

This doesn't address the questions about how the errors should be
handled, note!

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.

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.

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

- Dave



> > My suggestion would be to specify the behaviour of a "namespace
> > processor" -- distinct from an XML processor! -- and define its
> > behaviours in terms of the data provided to it by an XML processor
> > (driven either by parsing events or by some parse tree).  This
> > processor would only need markup related data as input.
> 
> This has to wait until we have a spec for what the output of an XML
> processor is, but I agree this would be a good way to explain it.
> 
> James

Received on Sunday, 16 August 1998 12:17:21 UTC