Boost logo

Boost :

From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2006-10-30 04:01:32

loufoque wrote:
> Sebastian Redl wrote:
>> Once again I'm turning to the list for discussion about a design issue
>> in the XML library. This time I hope to avoid any discussion about the
>> implementation on the library and focus on interface only.
> Have you thought about asynchronous parsing?
> How could that be available?
I have thought about it. A pull interface is not very suited for
asynchronous parsing, but it will provide non-blocking parsing
(returning a "would-block" event if not enough input is available).
The push interface will provide asynchronous parsing by somehow
registering with an ASIO io_service. I'll have to take a closer look at
ASIO to find out how exactly to realize this, though.
> There are of course variations, like the one Matt Gruenke revealed.
> You could provide the inheritance interface but with the objects
> actually owned by the parser (making it kind of like the monolithic
> interface), and use variant to store those objects on the stack.
> This idea doesn't look so bad actually, since you have the second
> solution without its drawbacks and that you only gain the advantages of
> the first solution (if you provide the appropriate tools to allow copy
> construction of the referenced objects, that is).
Yes, that sounds like a good solution indeed.
> I don't understand, though, if you mean that the parser containing its
> state is a good thing or not.
Neither. Both modes have advantages and disadvantages.
> Examples of how some basic operations could be done with those
> interfaces would come in handy to compare them for the ones, like me,
> that don't have much experience with parsing XML.
Yes, good idea. I'll work something up.
> Validation is quite costly: a way to prevent it would be nice. And it's
> not just DTD, there are other validation means.
Like Relax NG and Schema. I know. But as Stefan Seefeld correctly
posted, this is not about validation. This is about what to do with
errors that come up during validation and/or well-formedness checking.
> However, without validation you don't know what the `id' attribute is,
> which is quite annoying. It seems that's why they introduced xml:id.
> Browser engines like Gecko don't validate but they know what the id
> attributes are for each namespace that they handle. Maybe something
> similar could be done, be it with static data or user input.
I plan to support the xml:id specification, but not store any knowledge
of specific namespaces. Of course, there will be a way to feed the
validator programmatically, so this could be implemented easily on top
of that.
>> Should errors be reported as error events, or as
>> exceptions?
> We expect errors to happen, so we shouldn't use exceptions.
Do we? A SOAP server typically expects to receive programmatically
generated XML, so it ought to be error-free.
On the other hand, an XML-aware editor fully expects errors, because
they're guaranteed to be there in incomplete documents.
> We could allow them to be toggled on though, for users that don't want
> to check for such things and are not looking for super efficiency.
That's what I think, too.
> Maybe they should be using a higher level API then though.
Perhaps, but some people might have memory as their main constraint, not
speed. They would still want to use a low-level interface, yet not
expect errors.

Sebastian Redl

Boost list run by bdawes at, gregod at, cpdaniel at, john at