XOM API for Processing XML with Java

[Elliotte Harold <elharo AT metalab.unc.edu>]

Adam Constabaris wrote:

> However, I want the output to be validatable against the DocBook DTDs, 
> which creates a problem for me, since the xml:space attribute is not 
> defined in that DTD.

The real fix is to have DocBook support xml:space. I suspect that may 
not be as far away as you think. Check on the docbook-apps mailing list.

I do know DocBook uses a linespecific notation for such elements, but 
XOM doesn't support notations nor do I want to add it for something 
that's likely to disappear in favor of xml:space anyway.

Temporarily, could you provide an internal DTD subset that allows the 
xml:space attributes to validate?

> What would be ideal, from a programmatic standpoint, would be to be 
> able to 'virtualize' the attribute -- pretend it's there for purposes 
> of whitespace preservation, but don't actually output it.  One way I 
> could achieve this (I think) would be to call setPreserveSpace(true) 
> on the TextWriter used by Serializer for the 'preserving' elements.  
> However, the variable has private access to Serializer, so I'd have to 
> instantiate my own in my subclass (alarm bell one!). At any rate, the 
> TextWriter is package private, so this is definitely not possible for 
> a Serializer subclass that doesn't live in the same package (alarm 
> bell two). Even if it is, it looks like I might have to override more 
> than the one method (alarm bell three).


This is definitely a hack. Perhaps a simpler hack would be to override 
writeAttribute() in your subclass so it never writes xml:space 
attributes? They should still be seen by the Serializer and TextWriter 
though. TextWriter is deliberately non-public. I'm not perfectly happy 
with it and I want the freedom to change it completely in future 
releases without breaking anyone's code.

--
Elliotte Rusty Harold