there's a xmlserializer that is provided with xerces2 (org.apache.xml.serialize.XMLSerializer). I'm not sure if it's the best serializer available, but it certainly handles all the commented out cases in org.apache.xindice.xml.TextWriter. Most likely the static calls to TextWriter will need to be handled or re-written.
on a related note, i'm working on the storage of the DTD. i've made some minor modifications to org.apache.xindice.xml.dom.DOMParser which properly add the DocumentType element to the DOM tree. but the documenttype information disappears when the document is serialized. my test case just inserts a document. it appears that the calls in Collection.putDocument(Key, Document, boolean) that compress the document (via DOMCompressor.Compress) and recreate the Document object from the bytes are the culprit. So, i looked into the DOMCompressor.Compress method. i added a debug statement to the switch statement in Compress, but the Node.DOCUMENT_TYPE_NODE never seems to be called. I'm a little confused on this... can either of you provide pointers as to what i'm doing that's incorrect? thanks dave -----Original Message----- From: Kimbro Staken [mailto:[EMAIL PROTECTED] Sent: Monday, May 06, 2002 5:18 PM To: [EMAIL PROTECTED] Subject: Re: TextWriter discussion On Monday, May 6, 2002, at 04:12 PM, Fernando Padilla wrote: > > hello. > > I would like to open up a topic for discussing among the Xindice > community. > > I don't think it should be Xindice's responsibility to maintain a > proper(correct) XML serializing code. Attempting to do so will lead > to improper XML serialization. And I am willing to wager that the use of > our own implementation of XML serialization is at the root of the encoding > problems Xindice continues to face. > > So I feel we should get rid of TextWriter, or implement it as a wrapper > over more established XML serializing codebases, like Xerces ( if we can > depend on one parser ), or I believe TrAX is supposed to have serializing > hooks too. > > > This is just what I think, what do others think?? I believe the reason this was originally done was just performance and the ability to have an easier way to serialize things. I can't claim to know all the issues, but I definitely prefer to use existing code wherever possible so if the custom serializer can be replaced it's probably a good thing. > > > Fernando Padilla > > > Kimbro Staken Java and XML Software, Consulting and Writing http://www.xmldatabases.org/ Apache Xindice native XML database http://xml.apache.org/xindice XML:DB Initiative http://www.xmldb.org
