My question may seem silly, as it is trivial with an xsl or an XMLFilter to remove the xml declaration (i.e.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>) from the output of deltaxml, but from a cleanliness of design perspective, I would prefer to set a feature or property on the XMLComparator to disable the output of the xml declaration (neither of my input files have one).  Is this doable?  If not, I'll just write a simple stupid filter or xsl to remove this for me.

Hi,

Yes, this is perfectly possible using the setOutputProperty method on the PipelinedComparator. This method takes two Strings, the property name and the property value.

To set the property you need, use:

PipelinedComparator pc= new PipelinedComparator(); pc.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes");

where OutputKeys is imported from javax.xml.transform.

For details of other recognised output property settings, see the following Javadoc:

http://www.deltaxml.com/core/4.3.3/docs/api/com/deltaxml/core/PipelinedComparator.html#setOutputProperty(java.lang.String, java.lang.String)

Tristan

While what Tristan has said about PipelinedComparator is true and correct, he may have missed this aspect of the question.

Most users have one or more output filters, coded in either Java or XSLT, after the comparator and find the com.deltaxml.core.PipelinedComparator class easier to use than our older com.deltaxml.api.XMLComparator class.  We've been concentrating on the PipelinedComparator class (it wraps/calls XMLComparator internally, but shields users from all the complexity of JAXP based pipeline construction) and have been adding ease of use features here.

As originally noted, it is reasonably easy, when using XSLT to add something like:

<xsl:output omit-xml-declaration='yes'/>

to the final filter.

So I see this issue (missing XMLComparator feature) being significant when:
* using our older XMLComparator API
* not using any filters after the Comparator
   (it usually doesn't matter what the comparator does when the XML serialization is done by the final output filter,
   again a good reason to use PipelinedComparator)

We'll certainly take note and create a (trac) ticket for a enhancement request but unless anyone is overly concerned I would suggest we leave this inconsistency/limitation until we give our serialization/output code an overhaul.  We'll also help anyone using XMLComparator to move to PipelinedComparator if they wish.

Cheers,

Nigel

Thanks for your replies, Nigel and Tristan.   I'll either switch to using a pipelined comparator for the output, or add in something to strip off the declaration.  Just so you know why I don't use the PipelineComparator, it is because I liked the idea so much that I implemented a version myself that we use in several places.  I wanted to change things though so I could put in other transformations that can't be turned into an XMLFilter (e.g. I have Regex Transformations and EntityEncodingTransformations).  This allows all my clients to execute against a very simple interface, and I move the configuration of the entire pipeline, along with all the entity handling and reg ex transformations into a spring configuration. 

Given all that, it didn't make sense for me to use the pipelined comparator, since I had my own version and I wanted to just use the base comparator you provide. 

Thanks for your replies, Nigel and Tristan.   I'll either switch to using a pipelined comparator for the output, or add in something to strip off the declaration.  Just so you know why I don't use the PipelineComparator, it is because I liked the idea so much that I implemented a version myself that we use in several places.  I wanted to change things though so I could put in other transformations that can't be turned into an XMLFilter (e.g. I have Regex Transformations and EntityEncodingTransformations).  This allows all my clients to execute against a very simple interface, and I move the configuration of the entire pipeline, along with all the entity handling and reg ex transformations into a spring configuration. 

Given all that, it didn't make sense for me to use the pipelined comparator, since I had my own version and I wanted to just use the base comparator you provide. 

Its interesting to hear about your system:

... I liked the idea so much that I implemented a version myself that we use in several places.  I wanted to change things though so I could put in other transformations that can't be turned into an XMLFilter (e.g. I have Regex Transformations and EntityEncodingTransformations).  This allows all my clients to execute against a very simple interface, and I move the configuration of the entire pipeline, along with all the entity handling and reg ex transformations into a spring configuration.

I'll jot down some background and a few ideas about our future direction/plans in this area - it could be useful for people in similar situations and with or planning similar customizations:

The PipelinedComparator idea does have its limitations, it is an 80/20 type of design - we wanted to hide the JAXP pipeline construction complexity behind a simpler API for many of the common pipeline use-cases.  Long  time users may remember our Advanced.java JAXP sample code - we spent a lot of time explaining how to adapt/customize this code.   

One reason for being org.xml.sax.XMLFilter based is to keep a streaming architecture as far as possible - were we code Java filters as replacements for XSLT we get good memory footprint benefits;  these are often more significant than the CPU time benefits.  Converting the WordByWord filters from XSLT to Java provided some big benefits to users processing 100+ MB files with some of our pipelines.

There's one more feature I'd like to add to PipelinedComparator:  'Pull Parser' based filtering (a third type of input or output filter) - think of wrapped StAX or System.Xml.XmlReader based code.

Another idea we're considering is providing DeltaXML comparator components for other Pipeline systems.   These should provide a wider range of components/stages/tools than our simple model of chains of 'filters' - and perhaps something similar to your regexp transformers.  A NetKernel module is in progress which should allow the Comparator to be used in DPML pipelines and NetKernel more generally (its how we implement the sandboxes and services on this site).

We're also interested in the W3C XProc http://www.w3.org/TR/xproc/ standard and are considering providing a comparator step in one or more of the XProc implementations which are now becoming available.  I spent the weekend before last at XML Prague (papers and slides online:  http://www.xmlprague.cz/) where there was a lot of discussion on the topic of XML Pipelines.

Given all that, it didn't make sense for me to use the pipelined comparator, since I had my own version and I wanted to just use the base comparator you provide.

Yes I can appreciate that - we're still maintaining/supporting the base JAXP interface - so we will add this missing functionality at some point.  Customers with support contracts could influence the priority of this by asking through our enterprise support channels.

Cheers,

Nigel