[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GSXML test failures

From: Richard Frith-Macdonald
Subject: Re: GSXML test failures
Date: Thu, 14 Mar 2002 14:08:01 +0000

On Thursday, March 14, 2002, at 12:30 PM, Nicola Pero wrote:

Anyway - I came to the conclusion that the only way to fix is it is to
change the API of the GSXMLDocument, GSXMLNode and GSXMLNamespace classes
enforcing some much more strict relationships between the different
objects - each node *must* belong to a document (and retains the document,
and you can't build a node without a document); each namespace *must*
belong to a node (and retains the node, and you can't build a namespace
without a node); you can't unlink a node from a document, you can at most move the node from one place in the document to another place, or destroy
the node completely.

I think that is probably the best thing to do.

I don't understand the relationships of namespaces to nodes though.  Why
should a namespace be associated with a particular node?
Could we say that all namespaces must belong to a document rather than a node?

This only for the GSXML tree stuff - the GSXML SAX parser is fine instead
and seems to be working fine, I'm pretty happy with it (even if the API
could be improved).

I suppose the nice right way to go would be to rewrite the GSXML tree
stuff on top of the GSXML SAX handler ... in practice, rewriting part of
libxml2 in Objective-C. That would be nice and would free us from libxml2
backend memory problems ... but it's a lot of work and it would likely
require a lot of effort to be made to work.

The nicest thing (IMO) about libxm is that it can validate a document
against a DTD.   I *think* it needs to produce the parse tree to do that,
though I'm not sure.  So if we rewrote the tree code entirely on top of
the SAX handler, I think we would be throwing away that big advantage.

My feeling is it would be better to go with a restricted API where a node
is forever associated with a particular document than try re-implementing
the tree stuff.

I'm so happy with the GSXML SAX parser I think I will always use
that for parsing everything

I think SAX is fine for simple (most) documents, but having a tree structure which you know is validated to the DTD makes parsing of complex documents much easier because you can make all sorts of assumptions about the relationships between nodes (enforced by the DTD) rather than having to build up your own
data structure to record the actual relationships.

(and generate XML manually, even if for
generating XML some functionality more in the GSXML would be helpful, such
as methods XML-escaping strings for usage inside attributes or contents
etc), so I told Richard, but I've not rewritten anything.

XML escaping methods would be a very good addition.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]