Russell Potter wrote:
> ... But I also need to inderstand an XML proc-
> esssor's behaviour in snough detail to be able
> to implement one when I get to that stage.

If you need this level of understanding, I highly recommend the 
"Annotated XML Recommendation" -- a version of the XML 1.0 spec which 
Tim Bray reworked with hypertext links to explanations of what some of 
the obscure wording is intended to mean, why those decisions were made, 
and so on.

Note that to be useful for modern applications, an XML processor must 
_at_least_ implement not only XML, but XML Namespaces, and depending on 
what you're doing you may need other specs as well (XML Schema, for 
example). And there are issues like encodings (as you pointed out), 
serializers (going from in-memory representations back to XML syntax), 
etc. Plus subtleties in implementing the common XML APIs, if you aren't 
reinventing those from scratch.

If you're working in an environment for which a suitable processor isn't 
already available, you may not have any choice about implementing your 
own. Or you may have special needs -- sometimes applications of wheels 
are different enough to require reinventing; gears are different from 
tires or circular saw blades.

But in most cases it really is a lot easier to take advantage of the 
efforts the community has already put into making all of this work and 
tuning it for performance than to code it all de novo. Not least because 
that leaves you free to focus on implementing your actual application.