Re: GSXML test failures

[Richard Frith-Macdonald]

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.