Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] preseve whitespace in serialization w/o inserting xml:space

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: Adam Constabaris <adamc AT email.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] preseve whitespace in serialization w/o inserting xml:space
  • Date: Thu, 09 Sep 2004 12:02:10 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page