There are various settings that control the matching. Looking at this data it appears that you weren't using the enhanced matcher.

When I run this command:

java -jar /usr/local/DeltaXMLCore-5_0/command.jar compare delta f1.xml f2.xml f12.xml

I the following result (using the new deltaV2 format):

<footnotes xmlns:deltaxml="http://www.deltaxml.com/ns/well-formed-delta-v1" xmlns:dxa="http://www.deltaxml.com/ns/non-namespaced-attribute" deltaxml:deltaV2="A!=B">   <footnote deltaxml:deltaV2="A" alt="1" id="61177" label="1" order="2" size="1">     <para>New Footnote</para>   </footnote>   <footnote deltaxml:deltaV2="A!=B" alt="1" id="61178" order="2" size="1">     <deltaxml:attributes deltaxml:deltaV2="A!=B">       <dxa:label deltaxml:deltaV2="A!=B">         <deltaxml:attributeValue deltaxml:deltaV2="A">2</deltaxml:attributeValue>         <deltaxml:attributeValue deltaxml:deltaV2="B">1</deltaxml:attributeValue>       </dxa:label>     </deltaxml:attributes>     <para deltaxml:deltaV2="A=B">share report</para>   </footnote> </footnotes>

This command has the enhanced matcher turned on by default. With this command:

java -jar /usr/local/DeltaXMLCore-5_0/command.jar compare delta f1.xml f2.xml f12.xml "Enhanced Match 1=false"

I get a similar result to the one you posted.

If you are coding using the API see the feature settings information in the javadoc.

The enhanced matcher takes note of the PCData in the <para> child elements when aligning the <footnote> elements. There are other ways of aligning the footnotes, one of which is to assign higher priority to certain attributes using deltaxml:keys. Perhaps defining keys based on the id attribute would be appropriate in this case?

If so this can be achieved with an input XSLT filter which adds the deltaxml:key attribute to each of your footnote elements. Keys are discussed in http://www.deltaxml.com/dxml/library/how-to-use-keys.html and there is an interactive example.

And if you are looking for sample code, including an XSLT filter please see the AddressBook sample program in the release.

Now the matching is more appropriate, it should then be possible to address any issues with the attributes. You could decide to:

- remove the label attribute from the result
- use either the A or B values when there is a difference.

Are any of these appropriate? When you say you want to ignore an attribute change, what are you trying to achieve? We can provide some sample code but we need to understand the requirement a little more.

But my problem is totally different.  Please look at this problem I have attached the code also. I have two footnotes and i have deleted one and taking diff xml using deltaxml api. Please look at the code give provide me some samples.

old xml
<footnote alt="1" id="61177" label="1" order="2" size="1">   <para>New Footnote</para>
</footnote>
<footnote alt="1" id="61178" label="2" order="2" size="1">   <para>share report</para> 
</footnote>
new xml
<footnote alt="1" id="61178" label="1" order="2" size="1">   <para>share report</para> 
</footnote>
diff xml
<footnote id="61177" deltaxml:delta="WFmodify" alt="1" label="1" order="1" size="1">
    <para deltaxml:delta="WFmodify"><deltaxml:PCDATAmodify><deltaxml:PCDATAold>
      New Footnote</deltaxml:PCDATAold>
<deltaxml:PCDATAnew>share report</deltaxml:PCDATAnew></deltaxml:PCDATAmodify></para></footnote>
<footnote deltaxml:delta="delete" alt="1" id="61178" label="2" order="2" size="1"><para>share report.</para></footnote>

In the above new xml I have deleted one footnote and i want to compare the old and new xml. I have to get the result as first footnote as deleted. But i get the result as modified. For this i fount label  is same for the first element in both xml. So i want to ignore this  I would like to get the xsl file for this and do i have to set this as input filter or output filter.

DeltaXML Core 5.0 is now available.  This is a major new release
with these features:

  - A new delta format ('deltaV2') which is easier to
      process with XSLT/XPath/XQuery.

  - New filters and some new pipelines, particularly
      suited to document-centric XML.

  - Some API-level changes, including some new methods,
      improved error/exception handling and API
      house-keeping including the removal of some
      previously deprecated features.

Further details are provided in the release notes:

   http://www.deltaxml.com/core/current/docs/release-notes.html

While this release defaults to use the new delta format, the old
format is still available through a feature setting.  We would
encourage existing users to upgrade to the new format and filters.
However, support for users who wish to continue to use deltaV1
and the current filters is available via a 'Filter Compatibility Pack'
or 'FCP'.  For more information:

   http://www.deltaxml.com/library/filter-migration.html
   http://www.deltaxml.com/library/downloads.html

The feature-walkthroughs, sandboxes, online services and technical
documentation on the DeltaXML website have been updated to support this
release.  The following link provides an index to the documentation:

   http://www.deltaxml.com/library/index.html


Enterprise release customers with current support contracts can request
a Core 5.0 build be prepared and made available at their download area.

Evaluations of DeltaXML Core 5.0 are available to registered users of
the DeltaXML website.  We have reset all user records so that even if
you have previously had an evaluation you can now request a new
evaluation activation key for 5.0.  These can be used with the
5.0 download available from the website (after registered-user login).

Named-user and Professional-server customers with annual maintenance
will shortly receive their new activation keys via email.

As always, feedback is welcome via the website support forums or
via our usual support channels for enterprise customers.

Hi Jeff,

Thanks for the updates.  Stay tuned next week...

We've planned how to extend the customization layer - where we currently have 2 directories:
  dxml-fo
  dxml-html
We are going to add 2 more for namespaced docbook 5:
  dxml-fo-ns
  dxml-html-ns

The idea is that these can then be used with docbook-xsl-1.74.0 and docbook-xsl-ns-1.74.0 respectively.

This should be our docbook-changebars-0.1.3 release and should be available next week - together with the updated docbook pipeline(s) for our comparator.

Thanks,

Nigel

Forgot to mention, we're already using your docbook customization layers, but with output created by DiffMk. DiffMk has issues, however, that we have been unable to address, so we're arranging the approval for a commercial solution.

Hi Nigel,

In hindsight, I (of course) should have realized that the fact that added elements were being picked up and processed correctly ment that this couldn't possibly be a namespace issue. What can I say, I was tired.

The only thing missing is indeed the <phrase> element insertion.

The immediate need is for processing Docbook 5 documents, although we'll be needing to process DITA 1.4 documents within the next few months.

Jeff.

Hello JR,

I'm trying to add namespace awareness to the infilter and outfilter files, and am having some difficulty; the main issue that I have is that I'm not sure what the expected output of the infilter should look like.

We wrote the docbook-infilter.xsl when we knew docbook5 name namespaces were coming along - but we didn't know the details of which namespace was to be used.  So we've used the trick of matching on local-names only and using an identity transform.  I've just re-read the code and I believe that filter should work on both Docbook 4 and 5.  If the input has namespaces, so will the output of this filter.


To answer your question - pretty much like the input file with the addition of some attributes such as deltaxml:key, deltaxml:word-by-word, xml:space.  It is also intended to wrap the contents of certain elements (see line 101) in deltaxml:line elements.  None of the things added in the infilter are in the Docbook namespace.

At the moment, it appears to be processing everything normally, but Deltacore is still not picking on and marking changes done within the body a content element. What should I be looking for?

If you have a specific example of changes not being 'picked up' we'd like to hear about it.  It could be because docbook-outfilter is outputting elements in the wrong namespace if the rest of your pipeline is expecting to process Docbook5.

There is a little more work to be done with the docbook outfilter to update it for docbook5 and namespaces (it need to generate elements such as phrase in the new namespace).

And then there is work on our customization layer for docbook-xsl.  I was working on this during on long train journey on Friday (but that was 1.73.3 and 1.74 has just come out)...

We're busy working on our core 5.0 release this week (scheduled for release this week).  However, we've recently had a number of users ask for updates/improvements and docbook5 support and we are planning to address these next week.  So if you can hold on for a week or so you can expect us to provide updates to both the in/out-filters used in Core and also the customization layer to support docbook5.

Can I ask (to help with scheduling):  Are you also interested in using our docbook-xsl customization layer(s) or are you using some other publishing pipeline?

Cheers,

Nigel

I'm trying to add namespace awareness to the infilter and outfilter files, and am having some difficulty; the main issue that I have is that I'm not sure what the expected output of the infilter should look like. At the moment, it appears to be processing everything normally, but Deltacore is still not picking on and marking changes done within the body a content element. What should I be looking for?

Hello Troy,

We've investigated this by looking at the logs (and also the files which Troy emailed to our support email address).

One of the problems with the service is poor error reporting (we've probably introduced a bug since release).  This needs work on the code of the actual web-service itself.

As you may have discovered input files should not contain revisionflag attributes.

There was another issue with Troy's data when running XEP - were investigating this further.

The performance issues are something we've been addressing  - we introduced a catalog to improve performance when we found fetching the docbook DTDs from docbook.org was slow and we added the 4.3, 4.4 and 4.5 DTDs to the catalog.  Unfortunately Troy's files used the 4.2 DTDs.

Aside from the delays associated with fetching the DTDs there's not that much we can do to make things faster - its our own colocated server running the service and it has enough CPUs and RAM.  In some cases the three stage publishing pipeline (DeltaXML compare, docbook-xsl+customizations, XEP) just takes a longish time to run if the input documents are large.  Its possible the browser is just timing out waiting for the response from the server.

We will look at the service and several improvements are due soon (probably starting in the next 2 weeks):

- automatic removal of revisionflags on input documents
- add catalog support for more docbook DTDs
- add support for Docbook 5 and namespaces
- better error reporting
- consideration of new service models including separation of the upload, batch-processsing and then download to avoid timeouts

Any users of the service - please do report any problems you find here, feedback is welcome.  The components of the system are available for evaluation/download and you could run them locally if you have problems with data sizes and timeouts in the short term.   Running things locally also tends to work better if your docbook files reference images and you need these to appear in rendered results.


Nigel

After a half dozen attempts to compare docbook xml files, I think I was able to submit acceptable xml to the online comparison form, however, after 60-70 seconds of processing I get a 'Internet Explorer cannot display the webpage' message.

The options were for docbook xml with revisionflags, no validation, no word by word and 2 uploaded files.