You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(2) |
Feb
(8) |
Mar
|
Apr
|
May
(2) |
Jun
(4) |
Jul
(1) |
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
(2) |
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
| 2007 |
Jan
(12) |
Feb
(17) |
Mar
(13) |
Apr
(20) |
May
(36) |
Jun
(5) |
Jul
(3) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(11) |
Dec
(5) |
| 2008 |
Jan
(9) |
Feb
(3) |
Mar
(19) |
Apr
(20) |
May
(8) |
Jun
(18) |
Jul
(1) |
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(4) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(3) |
Apr
(6) |
May
(12) |
Jun
(6) |
Jul
(2) |
Aug
(2) |
Sep
(5) |
Oct
(4) |
Nov
(2) |
Dec
(2) |
| 2010 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(3) |
May
(5) |
Jun
(2) |
Jul
|
Aug
(4) |
Sep
(3) |
Oct
(3) |
Nov
|
Dec
(3) |
| 2011 |
Jan
(2) |
Feb
(10) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(4) |
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(13) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(5) |
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(17) |
| 2015 |
Jan
(28) |
Feb
(33) |
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
(1) |
| 2016 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
(4) |
| 2022 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
|
From: Stefan B. <bo...@ap...> - 2010-08-24 15:50:30
|
On 2010-08-21, Lanam, Jeff wrote: > Alternatively, I could use a method that compares an abbreviated > reference like the one above, with an expanded one. > In the example above, getXPathLocation returns > /mydoc[1]/child[1]/city[1]/text()[1] . I need a way to determine that > this is equivalent to "//child[@name='Dick']/city". This is pretty hard to do without using a full XPath engine on the documents you compare - I hoped James had an idea, but now I'll try to jump in. Except in really trivial cases you can't say whether two XPath expression yield the same node(s) (or even just intersecting sets of nodes) without the context of the document you want to apply the XPath to. When you receive the Difference, you get a Node instance as well as the XPath. The XPath doesn't provide enough information for your requirements, you'd have to travel up (Node#getParentNode) to the "child" element and then consult its name attribute. It may be easier to apply your XPath expression to the document (Node#getOwnerDocument) and see whether the Node at hand is part of the NodeLists that matches the XPath. You could use org.custommonkey.xmlunit.XMLUnit.newXpathEngine() for this or JAXP directly (see the javax.xml.xpath namespace). In your example the answer would be "no" since the city element matches the XPath expression not its nested text which is the Node you receive in the Difference - you may need to adapt here. Stefan |
|
From: Lanam, J. <jef...@hp...> - 2010-08-20 22:26:57
|
From: James Abley [mailto:jam...@gm...]
Sent: Friday, August 20, 2010 3:34 AM
To: Lanam, Jeff
Cc: xml...@li...
Subject: Re: [Xmlunit-general] Comparing XPath expressions in DifferenceEngine
On 20 August 2010 01:31, Lanam, Jeff <jef...@hp...<mailto:jef...@hp...>> wrote:
I’m trying to write a DifferenceEngine for XMLUnit 1.3 that will allow or reject differences based on a list of elements specified by the user. I have a simple one working which just compares the element names, but I would like to use XPath expressions for more precise specification. The problem I have is that the Difference.getTestNodeDetail().getXpathLocation() method returns a non-abbreviated expression, but I want the user to be able to use abbreviated syntax. Is there a way to compare two XPath expressions, using the control document as a reference, and determine if they are referencing the same element? XPath is new to me, and I haven’t done much with XSLT or Java XML APIs. Thanks for any help.
Jeff Lanam
Hewlett-Packard
Hi Jeff,
Can you supply a test which indicates what you're trying to do?
Cheers,
James
----------------------------------
Thanks for responding, James. Here’s a test that shows what I want:
@Test
public void test_DuplicateName() throws XpathException, SAXException, IOException
{
String control =
"<mydoc><child name=\"Tom\"><city>Chicago</city></child>" +
"<child name=\"Dick\"><city>Memphis</city></child>" +
"</mydoc>";
String data =
"<mydoc><child name=\"Tom\"><city>Cleveland</city></child>" +
"<child name=\"Dick\"><city>Memphis</city></child>" +
"</mydoc>";
XPathInclusionDifferenceListener dl =
new XPathInclusionDifferenceListener(
new String[]{"//child[@name='Dick']/city"}, control);
Diff diff = new Diff(control, data);
diff.overrideDifferenceListener(dl);
assertXMLEqual("compare Dick's city", diff, true);
}
The DifferenceListener method differenceFound should determine if the XPath location of the difference it’s passed is contained in the array of XPath references passed to the constructor. If it is, then differenceFound should return RETURN_ACCEPT_DIFFERENCE. Otherwise, it should return RETURN_IGNORE_DIFFERENCE_NODES_IDENTICAL.
The code below shows what I’m trying to implement. The missing piece is the method expandXPathReference.
Alternatively, I could use a method that compares an abbreviated reference like the one above, with an expanded one.
In the example above, getXPathLocation returns “/mydoc[1]/child[1]/city[1]/text()[1]”. I need a way to determine that this is equivalent to "//child[@name='Dick']/city".
public class XPathInclusionDifferenceListener implements DifferenceListener
{
Document document_ = null;
Set<String> includedElements_ = new HashSet<String>();
static XpathEngine engine_ = XMLUnit.newXpathEngine();
public XPathInclusionDifferenceListener(String includedElements[],
String docString) throws XpathException, SAXException, IOException
{
super();
document_ = XMLUnit.buildControlDocument(docString);;
setIncludedElements(includedElements);
}
/* (non-Javadoc)
* @see org.custommonkey.xmlunit.DifferenceListener#differenceFound(org.custommonkey.xmlunit.Difference)
*/
@Override
public int differenceFound(Difference difference)
{
String nodeName =
difference.getTestNodeDetail().getXpathLocation();
String expanded = null;
try
{
expanded = expandXPathReference(nodeName, document_);
}
catch (XpathException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
if(includedElements_.contains(expanded))
{
return DifferenceListener.RETURN_ACCEPT_DIFFERENCE;
}
return DifferenceListener.RETURN_IGNORE_DIFFERENCE_NODES_IDENTICAL;
}
/* (non-Javadoc)
* @see org.custommonkey.xmlunit.DifferenceListener#skippedComparison(org.w3c.dom.Node, org.w3c.dom.Node)
*/
@Override
public void skippedComparison(Node control, Node test)
{
// TODO Auto-generated method stub
}
/**
* @return the collection of strings that specifies which elements are significant
*/
public Collection<String> getIncludedElements() {
return includedElements_;
}
/**
* Sets the collection of strings that specifies which elements are significant.
* @param elements an array of strings which must be XML element names
* @throws XpathException
*/
public void setIncludedElements(String elements[]) throws XpathException {
for (String e : elements) {
includedElements_.add(expandXPathReference(e, document_));
}
}
private String expandXPathReference(String e, Document document)
throws XpathException
{
// TODO Replace e with the fully expanded XPath reference
return e;
}
}
|
|
From: James A. <jam...@gm...> - 2010-08-20 10:34:10
|
On 20 August 2010 01:31, Lanam, Jeff <jef...@hp...> wrote: > I’m trying to write a DifferenceEngine for XMLUnit 1.3 that will allow or > reject differences based on a list of elements specified by the user. I have > a simple one working which just compares the element names, but I would like > to use XPath expressions for more precise specification. The problem I have > is that the Difference.getTestNodeDetail().getXpathLocation() method > returns a non-abbreviated expression, but I want the user to be able to use > abbreviated syntax. Is there a way to compare two XPath expressions, using > the control document as a reference, and determine if they are referencing > the same element? XPath is new to me, and I haven’t done much with XSLT or > Java XML APIs. Thanks for any help. > > > > Jeff Lanam > > Hewlett-Packard > > Hi Jeff, Can you supply a test which indicates what you're trying to do? Cheers, James |
|
From: Lanam, J. <jef...@hp...> - 2010-08-20 00:33:48
|
I'm trying to write a DifferenceEngine for XMLUnit 1.3 that will allow or reject differences based on a list of elements specified by the user. I have a simple one working which just compares the element names, but I would like to use XPath expressions for more precise specification. The problem I have is that the Difference.getTestNodeDetail().getXpathLocation() method returns a non-abbreviated expression, but I want the user to be able to use abbreviated syntax. Is there a way to compare two XPath expressions, using the control document as a reference, and determine if they are referencing the same element? XPath is new to me, and I haven't done much with XSLT or Java XML APIs. Thanks for any help. Jeff Lanam Hewlett-Packard |
|
From: Stefan B. <bo...@ap...> - 2010-06-16 11:10:45
|
[I had to moderate in this post, please subscribe to the list] > There is no enough documentation provided for .Net. This is absolutely true. On top of that, the .NET code can't do many things the Java code base can, so you are likely not even getting close to what you can do with the Java version right now. I've set out to change this with XMLUnit 2.0 which I've been talking about for years now. Nothing tangible on the difference engine side, but svn trunk already contains validation and XPath code bases that are more or less identical for Java and .NET as well as skeleton ideas for the difference engine. This doesn't help you now, I now. > I tried adding xmlunit reference and tried to find the DifferenceLinstener > and Diff class which I could not find. The best source of documentation is the code and the unit tests. <http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/tags/XMLUnit.NET-0.4/src/csharp/> <http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/tags/XMLUnit.NET-0.4/tests/csharp/> Diff is XmlDiff and there is no equivalent of DifferenceListener at all, sorry. Stefan |
|
From: SUDHAKAR V <v.r...@gm...> - 2010-06-15 22:06:15
|
What is the .Net equivalent code for the below Java code?
*public* *void* testCompareToSkeletonXML() *throws* Exception {
String myControlXML = "<location><street-address>22 any
street</street-address><postcode>XY00 99Z</postcode></location>";
String myTestXML = "<location><street-address>20 east
cheap</street-address><postcode>EC3M 1EB</postcode></location>";
DifferenceListener myDifferenceListener =
*new*IgnoreTextAndAttributeValuesDifferenceListener();
Diff myDiff = *new* Diff(myControlXML, myTestXML);
myDiff.overrideDifferenceListener(myDifferenceListener);
assertTrue("test XML matches control skeleton XML " + myDiff,
myDiff.similar());
}
There is no enough documentation provided for .Net.
I tried adding xmlunit reference and tried to find the DifferenceLinstener
and Diff class which I could not find.
--Regards,
svangeti.
|
|
From: Stefan B. <bo...@ap...> - 2010-05-28 04:20:14
|
On 2010-05-28, Johannes Lichtenberger wrote: > I've got two HTML documents (serialized as XML) which have slightly > different structures at the end because of a stylesheet template rule > based on attributes (and attribute order isn't defined in XML documents > I think): Order of XML attributes is supposed to be irrelevant, still XMLUnit (1.x for Java) has a difference type for it, but it is considered recoverable. I don't see any attributes on your HTML anyway. > <h4>CATEGORY I</h4> > <table> > <tr> > <td>DESC</td> > <td>Paperback</td> > </tr> > <tr> > <td>CODE</td> > <td>P</td> > </tr> > </table> > vs. > ... > <h4>CATEGORY I</h4> > <table> > <tr> > <td>CODE</td> > <td>P</td> > </tr> > <tr> > <td>DESC</td> > <td>Paperback</td> > </tr> > </table> > You can see that only the tr-elements are exchanged, It's a bit more complex than that. You have to look at the <tr>'s grandchildren (the text nodes inside the <td> elements) to see which <tr>s to match. > but assertXMLEqual fales, even if I change the table structure to > unordered lists, so I assume it's not doable XMLUnit needs help from you to know which <tr>s to compare with each other. This is the purpose of the ElementQualifier <http://xmlunit.sourceforge.net/userguide/html/ar01s03.html#ElementQualifier>. In your case an ElementNameAndTextQualifier wouldn't be enough since you need to match <tr>'s based on the text of their children. RecursiveElementNameAndTextQualifier may work. Stefan |
|
From: Johannes L. <Joh...@un...> - 2010-05-28 02:15:06
|
Hi,
I've got two HTML documents (serialized as XML) which have slightly
different structures at the end because of a stylesheet template rule
based on attributes (and attribute order isn't defined in XML documents
I think):
...
<h4>CATEGORY I</h4>
<table>
<tr>
<td>DESC</td>
<td>Paperback</td>
</tr>
<tr>
<td>CODE</td>
<td>P</td>
</tr>
</table>
<hr/>
<h4>CATEGORY II</h4>
<table>
<tr>
<td>DESC</td>
<td>Mass-market Paperback</td>
</tr>
<tr>
<td>CODE</td>
<td>MMP</td>
</tr>
</table>
vs.
...
<h4>CATEGORY I</h4>
<table>
<tr>
<td>CODE</td>
<td>P</td>
</tr>
<tr>
<td>DESC</td>
<td>Paperback</td>
</tr>
</table>
<hr/>
<h4>CATEGORY II</h4>
<table>
<tr>
<td>CODE</td>
<td>MMP</td>
</tr>
<tr>
<td>DESC</td>
<td>Mass-market Paperback</td>
</tr>
</table>
You can see that only the tr-elements are exchanged, but assertXMLEqual
fales, even if I change the table structure to unordered lists, so I
assume it's not doable (maybe only if 2 nodes are really adjacent (and
changed in order) the algorithm finds similar documents).
The strange thing is it doesn't find similarities with the following
fragment (CODE and DESC exchanged in the other document):
<h4>CATEGORY I</h4>
<ul>
<li>CODE</li>
<li>DESC</li>
</ul>
vs.
<h4>CATEGORY I</h4>
<ul>
<li>DESC</li>
<li>CODE</li>
</ul>
I've simply used assertXMLEqual, maybe I'll try it with Diff and
diff.similar(), but it should be the same according to the docu.
regards,
Johannes
|
|
From: Stefan B. <bo...@ap...> - 2010-05-17 11:24:24
|
Hi, I'm writing this mail in part to share my thoughts and get feedback and in part to help myself get a clearer picture of how I want the difference engine of XMLUnit 2.0 to work. It won't be too different from the Java version of 1.x. The difference engine compares (I)Source instances, there are already plenty of implementations of this interface and even a fluid builder API to create such instances. Many of XMLUnit Java's options will be resolved by specialized Source implementations. There will be a CommentLessSource decorator which strips the comments from an existing Source as a way to emulate XMLUnit.setIgnoreComments for example. This should also apply to all whitespace manipulations. The difference engine is supposed to traverse the document tree from the root in a depth first search manner. Even though the initial implementation will be DOM based I hope it will be possible to provide pull parser (StAX or XMLReader based) or event driven (SAX) implementations that have the potential to compare bigger documents. As the engine traverses the tree it will compare certain aspects of the nodes - I guess I'll need to document properly which aspects that are going to be and in which order the comparisons occur. Basically these comparisons will all be testing for exact equality. If a comparison results in something that is not equal the registered DifferenceEvaluator will be consulted (passing in ComparisonResult.DIFFERENT) and will determine whether the difference is recoverable (in the same sense as the term was used in 1.x), non-recoverable or non-recoverable and comparison should stop at this point. The default implementation is more or less the same as of XMLUnit 1.x, the main difference is that a Text node and a CDATA node of the same textual content compare as recoverably different. ComparisonListeners can be attached to the DifferenceEngine and will - at this point - be notified of the comparison and its outcome. Listeners take interest in successfull, failed or all comparisons and will be notified based on the outcome. If the DifferenceEvaluator instructed the DifferenceEngine to stop, the comparison gets aborted otherwise the tree traversal continues. The remaining interface/delegate is ElementSelector which replaces 1.x's ElementQualifier. I'm a bit torn whether a selector based on the element's name should be the default (as it is in 1.x) or a pure order based one. The ElementSelector gets two DOM Elements of the control and test docs and decides whether they can be compared. This may require materializing the DOM tree below each element for non-DOM implementations - I hope to be able to do so in a lazy manner somehow if/whenever I start implementing such engines. The ElementSelector will be invoked whenever the child elements of an Element are to be compared and there is more than one child. In a forum thread somebody raised the idea to defer default element selection to the DifferenceEngine itself if there is no explicit ElementSelector, i.e. compare a combination of Elements and try a different one if the comparison doesn't have a successfull outcome. In order to avoid duplicate comparisons this would require queueing up comparisons to notify the listeners once the Elements are selected. At least I want to toy with the idea. Stefan |
|
From: Stefan B. <bo...@ap...> - 2010-05-04 04:19:52
|
Hi all, trunk [1] now has Java and .NET interfaces for a difference engine that can do what the Java version of XMLUnit 1.3 does. The plan is to add DOM based implementations and port the XMLUnit Java 1.3 code base to use it. The ideas are very similar to XMLUnit 1.3 but with a few twists. Instead of Difference there is a Comparison and an independent ComparisonResult which represent "this is what I compared" and "this is what I think of the outcome". ComparisonListeners get notified of each Comparison, each passing Comparison (replaces MatchTracker) or each failed Comparison (replaces part of DifferenceListener). ComparisonListener is a one-method interface in Java and a delegate in .NET and it is possible to attach multiple of them to the DifferenceEngine (using an event in .NET). ElementSelector (a delegate in .NET) replaces ElementQualifier - there can only be one per DifferenceEngine. DifferenceEvaluator may alter the outcome of a comparision and tell the DifferenceEngine to stop the comparision - replaces the remaining part of DifferenceListener and ComparisonControler. Again a delegate in .NET and there can only be one per DifferenceEngine. I intend to remove the ATTRIBUTE_ORDER difference type completely (there is no guarantee the parser will return them in document order anyway) and may choose to use a few different defaults from XMLUnit 1.x (like calling Text and CDATA nodes with the same content similar). Feedback more than welcome. Stefan [1] http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/src/main/java-core/net/sf/xmlunit/diff/ http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/src/main/net-core/diff/ but you better check out https://xmlunit.svn.sourceforge.net/svnroot/xmlunit/trunk/xmlunit for a full picture |
|
From: Stefan B. <bo...@ap...> - 2010-05-04 04:08:11
|
Hi all, over the past week I've added an XPath engine to both the Java and .NET code in trunk[1] (which once may become XMLUnit 2.0). The API is pretty similar[2] to that of XMLUnit Java 1.x and the Java implementation is based on JAXP 1.3. The .NET version uses XmlDocument for one method and System.Xml.XPath for the other. The java-legacy part of trunk which is supposed to implement XMLUnit Java 1.x in terms of the new code base uses the new XPath code in its JAXPXpathEngine and still passes its own tests. It may be a good idea to account for compiled XPath expression in the interface in some way, but right now my focus has shifted to the difference engine. Stefan [1] http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/src/main/java-core/net/sf/xmlunit/xpath/ http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/src/main/net-core/xpath/ but you better check out https://xmlunit.svn.sourceforge.net/svnroot/xmlunit/trunk/xmlunit for a full picture [2] method names are different and it returns an Iterable<Node> rather than a NodeList |
|
From: Stefan B. <bo...@ap...> - 2010-04-15 04:22:22
|
On 2010-04-14, Sneha Teckchandani <sne...@gm...> wrote:
> FYI - I had posted the same query to the mailing list as well. Now
> marking this email to it too.
You are not subscribed to the list so your mails end up in the
moderation queue and I simply didn't recognize it between all the SPAM
that the list receives (about one legitimate email is hidden between
several hundred SPAM messages, the list receives about ten SPAM messages
each day).
> Due to the lack of XMLUnit awareness around me, i turn to you for a
> detailed discussion.
That's what we are here for. 8-)
> I would like to records of my XMLs being compared instead of Line by
> Line comaprison (records with unique identifiers). We used the
> ElementNameQualifier Interface, did override it but it did not bring
> about record comparison.
> <Code> ElementQualifier overriden.
> public boolean qualifyForComparison(Element arg0, Element arg1)
> {
> try
> {
> if (arg0.getNodeName() != null
> && arg0.getNodeName().equals("POI")) /*Record Identifier is
> the firstChild Node of teh Elelment POI and hence item(0)*/
> {
> if(arg0.getChildNodes().item(0).getTextContent()
> .equals(arg1.getChildNodes().item(0).getTextContent()))
> return true;
> else
> return false;
> }
> }
> catch (Throwable t)//TODO add asserts
> {
> return false;
> }
> return true;
> }
> <code>
OK, let me see. You expect documents like
<container>
<POI ...>
<some-element-name>ID1</some-element-name>
</POI>
<POI ...>
<some-element-name>ID2</some-element-name>
</POI>
</container>
and want to compare elements with matching IDs, right? In general I'd
expect RecursiveElementNameAndTextQualifier to work here, so I may be
missing a detail.
Your code assumes that calling getChildNodes().item(0) on a POI element
will return the Node corresponding to the element some-element-name - is
this true? In my snippet above you'd likely first get a Text child node
containing a linebreak and four spaces. You probably should make
XMLUnit and your ElementQualifier ignore whitespace.
Can you provide example snippets of real XML documents you are trying to
compare?
Stefan
|
|
From: Stefan B. <bo...@ap...> - 2010-03-25 09:26:53
|
On 2010-03-25, James Sewell <Jam...@ar...> wrote:
> After a bit of playing I got it to work with JAXP 1.4!
Great
> SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
> Schema schema = factory.newSchema();
> Source ss = new StreamSource(inputstream, uri);
> Validator v = schema.newValidator();
> v.validate(ss);
this should be equivalent to XMLUnit's JAXP 1.3 validation with
Validator v = new Validator();
StreamSource is = new StreamSource(inputstream, uri);
boolean isValid = v.isInstanceValid(is);
if not, we should try to figure out why.
Stefan
|
|
From: James S. <Jam...@ar...> - 2010-03-25 00:04:51
|
After a bit of playing I got it to work with JAXP 1.4!
SchemaFactory factory = SchemaFactory.newInstance("http://www.w3.org/2001/XMLSchema");
Schema schema = factory.newSchema();
Source ss = new StreamSource(inputstream, uri);
Validator v = schema.newValidator();
v.validate(ss);
Thanks for the help Stefan.
James.
-----Original Message-----
From: Stefan Bodewig [mailto:bo...@ap...]
Sent: Monday, 22 March 2010 11:44 PM
To: xml...@li...
Subject: Re: [Xmlunit-general] xmlunit and setSystemId
On 2010-03-22, James Sewell <Jam...@ar...> wrote:
> From looking at JAXP 1.3 I still can't see a way of defining an
> absolute URI to use when working with relative schema locations
> (unless this is what a ResourceResolver is for??)
Honestly I'm not sure whether ResourceResolver would be used for
schemaLocation hints since the docs (for
SchemaFactory#setResourceResolver) only talk about import and include.
It may be worth a try, but I'm afraid XMLUnit currently wouldn't give
you the access you'd need.
> As mentioned all my schema location information is included by way of
> xsi:SchemaLocation elements, but as they are relative (to the original
> XML document location) I need to be able to define a URI to use as a
> base.
If you are specifiying your input (the XML document) as a Source
instance it may be sufficient if this Source has the correct system ID.
I know you've tried that for the SAX InputSource used in the "old"
validation API, maybe JAXP13's take will yield better results.
> I could grab the elements from the XML document and use these schemas
> with addSchemaSource, but it seems like this should be unnecessary?
I agree there should be a better way. Unfortunately I haven't played
with that part of JAXP too much, so I can't help much more than ask you
to try out things.
Stefan
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Xmlunit-general mailing list
Xml...@li...
https://lists.sourceforge.net/lists/listinfo/xmlunit-general
The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.
|
|
From: Stefan B. <bo...@ap...> - 2010-03-22 12:43:50
|
On 2010-03-22, James Sewell <Jam...@ar...> wrote: > From looking at JAXP 1.3 I still can't see a way of defining an > absolute URI to use when working with relative schema locations > (unless this is what a ResourceResolver is for??) Honestly I'm not sure whether ResourceResolver would be used for schemaLocation hints since the docs (for SchemaFactory#setResourceResolver) only talk about import and include. It may be worth a try, but I'm afraid XMLUnit currently wouldn't give you the access you'd need. > As mentioned all my schema location information is included by way of > xsi:SchemaLocation elements, but as they are relative (to the original > XML document location) I need to be able to define a URI to use as a > base. If you are specifiying your input (the XML document) as a Source instance it may be sufficient if this Source has the correct system ID. I know you've tried that for the SAX InputSource used in the "old" validation API, maybe JAXP13's take will yield better results. > I could grab the elements from the XML document and use these schemas > with addSchemaSource, but it seems like this should be unnecessary? I agree there should be a better way. Unfortunately I haven't played with that part of JAXP too much, so I can't help much more than ask you to try out things. Stefan |
|
From: Stefan B. <bo...@ap...> - 2010-03-19 10:09:06
|
Hi James,
On 2010-03-19, James Sewell <Jam...@ar...> wrote:
> try {
> v = new org.custommonkey.xmlunit.Validator(is);
> v.useXMLSchema(true);
> if (!v.isValid()) {
> throw new ValidationError(v.toString());
> }
You may consider using the JAXP 1.3 validator instead when you do schema
validation (if your Java class library supports JAXP 1.3, that is), see
<http://xmlunit.sourceforge.net/userguide/html/ar01s04.html#JAXP%201.3%20Validation>.
Using this you have more control over your schema locations.
> I realize that because I am using an InputSource I have lost any
> location information from my XML, so I have tried using
> is.setSystemId(http://www.test.org);
system ID really is something from the DTD part of XML's heritage, you
could explicitly specify this using one of the alternative constructors
of Validator. It doesn't help, though, since the system ID is not what
the XML parser is going to use for schema locations.
If you want or must stick to the older API, the Validator's
setJAXP12SchemaSource() is what you are looking for, see
<http://xmlunit.sourceforge.net/userguide/html/ar01s04.html#XML%20Schema%20Validation>
Cheers
Stefan
|
|
From: James S. <Jam...@ar...> - 2010-03-19 05:29:38
|
Greetings,
Chances are I am missing something critical here, but here goes anyway.
I am trying to validate some xml as follows:
InputSource is = new InputSource(new StringReader(response));
Validator v;
try {
v = new org.custommonkey.xmlunit.Validator(is);
v.useXMLSchema(true);
if (!v.isValid()) {
throw new ValidationError(v.toString());
}
An example of a test XML doc (let's say this is from www.test.org/sample.xml) I have been using is as follows:
<person xmlns="http://www.cafeconleche.org/namespaces/person" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.test.org/namespaces/person
person.xsd"><http://www.elharo.com/person.xs%22%3e>
<name>
<first_name>Alan</first_name>
<last_name>Turing</last_name>
</name>
<profession>computer scientist</profession>
<profession>mathematician</profession>
<profession>cryptographer</profession>
</person>
In this example xmlunit will try to grab person.xsd from my local machine's working directory. I want it to grab it from www.test.org/person.xsd<http://www.test.org/person.xsd> (I would like to avoid putting an absolute path in though).
I realize that because I am using an InputSource I have lost any location information from my XML, so I have tried using
is.setSystemId(http://www.test.org);
to set the relative path. This doesn't seem to have worked.
I am guessing I am misunderstanding something here, any ideas?
Cheers,
James Sewell
________________________________
The contents of this email are confidential and may be subject to legal or professional privilege and copyright. No representation is made that this email is free of viruses or other defects. If you have received this communication in error, you may not copy or distribute any part of it or otherwise disclose its contents to anyone. Please advise the sender of your incorrect receipt of this correspondence.
|
|
From: Stefan B. <bo...@ap...> - 2010-02-18 14:54:07
|
On 2010-02-17, Nicholas W <44...@lo...> wrote: > I can check that a piece of XML validates with an XSD that I have in a > jar like this: [snip] > And I can assert that two pieces of XML are similar like this: [snip] > But how can I compare two XML strings that are conformant to an XSD in > a jar? I'm not sure I understand what you want. You've already shown how two compare two XML strings so what else do you need? Are you looking for a way to assert that two pieces of XML conform to the same schema and are similar? There is no built-in way to do that, you have to implement it in three steps just as you've shown. Stefan |
|
From: Nicholas W <44...@lo...> - 2010-02-17 16:06:32
|
I can check that a piece of XML validates with an XSD that I have in a
jar like this:
InputSource xmlSource = resourceAsInputSource(resourcepath);
InputSource xsdInputSource = resourceAsInputSource(XsdPath);
xsdInputSource.setSystemId(xsduri);
assertNotNull(xsdInputSource);
Validator validator = new Validator(xmlSource);
validator.useXMLSchema(true);
validator.setJAXP12SchemaSource(xsdInputSource);
assertXMLValid(validator);
And I can assert that two pieces of XML are similar like this:
assertNotNull(result);
assertNotNull(resourcelocation);
log.debug(String.format("AssertStringXMLLikeResourceXML(%s)",resourcelocation));
saveResultCopy(result, resourcelocation);
InputStream resourceAsStream = this.getClass().getClassLoader()
.getResourceAsStream(resourcelocation);
assertNotNull(resourceAsStream);
String readerToString = FileIO.readerToString(new BufferedReader(
new InputStreamReader(resourceAsStream,"utf-8")));
log.debug(String.format("expected XML - %s",readerToString));
assertXMLEqual(readerToString,result);
But how can I compare two XML strings that are conformant to an XSD in a jar?
I need to do this as the XSD use xs:all and minOccurs=0 in the
xs:element to indicate that some elements are optional and can appear
in any order. The XMLs I wish to compare do have the elements in a
different order, but need to be considered the same and the test
should pass.
Thanks in advance for your help,
Regards,
|
|
From: Stefan B. <bo...@ap...> - 2009-12-15 13:01:29
|
On 2009-12-15, Dubey, Tarun <Tar...@sa...> wrote:
> The following test case fails while according to the javadocs of
> similar() method in Diff this should pass
> @Test
> public void testXmlIgnoreOrder() throws IOException, SAXException {
> XMLUnit.setIgnoreWhitespace(true);
> XMLUnit.setIgnoreAttributeOrder(true);
> String xml1 =
> "<TEST><FLIGHT NUM=\"121\"></FLIGHT><FLIGHT
> NUM=\"122\"></FLIGHT></TEST>";
> String xml2 =
> "<TEST><FLIGHT NUM=\"122\"></FLIGHT><FLIGHT
> NUM=\"121\"></FLIGHT></TEST>";
> Diff diff = XMLUnit.compareXML(xml1, xml2);
> Assert.assertTrue(diff.similar());
> }
No, it should fail. IgnoreAttributeOrder affects whether the order of
attributes of a single element is significant. All your elements only
have a single attribute, so order of them is the same anyway.
What is different is the order of elements.
If the order of elements is not significant to you, you'll have to help
XMLUnit decide which elements to compare by overriding the
ElementQualifier. The default implementations only looks at element
names, if the names are the same, it will compare the elements.
> Surprisingly the same test passes if the element names are different as
> shown below
> "<TEST><FLIGHT NUM=\"121\"></FLIGHT><CRUISE
> NUM=\"122\"></CRUISE></TEST>";
Yes. If the names are different, the FLIGHT elements and the CRUISE
elements get matched against each other. If they are the same, XMLUnit
will match them in the order they occur.
You want to use an ElementNameAndAttributeQualifier
<http://xmlunit.sourceforge.net/userguide/html/ar01s03.html#ElementNameAndAttributeQualifier>
Stefan
|
|
From: Dubey, T. <Tar...@sa...> - 2009-12-15 06:18:18
|
Hi,
The following test case fails while according to the javadocs of
similar() method in Diff this should pass
@Test
public void testXmlIgnoreOrder() throws IOException, SAXException {
XMLUnit.setIgnoreWhitespace(true);
XMLUnit.setIgnoreAttributeOrder(true);
String xml1 =
"<TEST><FLIGHT NUM=\"121\"></FLIGHT><FLIGHT
NUM=\"122\"></FLIGHT></TEST>";
String xml2 =
"<TEST><FLIGHT NUM=\"122\"></FLIGHT><FLIGHT
NUM=\"121\"></FLIGHT></TEST>";
Diff diff = XMLUnit.compareXML(xml1, xml2);
Assert.assertTrue(diff.similar());
}
Surprisingly the same test passes if the element names are different as
shown below
@Test
public void testXmlIgnoreOrder() throws IOException, SAXException {
XMLUnit.setIgnoreWhitespace(true);
XMLUnit.setIgnoreAttributeOrder(true);
String xml1 =
"<TEST><FLIGHT NUM=\"121\"></FLIGHT><CRUISE
NUM=\"122\"></CRUISE></TEST>";
String xml2 =
"<TEST><CRUISE NUM=\"122\"></CRUISE><FLIGHT
NUM=\"121\"></FLIGHT></TEST>";
Diff diff = XMLUnit.compareXML(xml1, xml2);
Assert.assertTrue(diff.similar());
}
Is this bug already been reported ? If yes please can you let me know
where to find the fix or a workaround ?
Thanks
Tarun Dubey
|
|
From: Stefan B. <bo...@ap...> - 2009-11-17 05:21:38
|
On 2009-11-16, max muster <beh...@go...> wrote: > How to validate a Word 2007 XML file against a Schema? > Is it possible to use XMLUnit to formulate a Testcase? Yes, it is, I'm just not sure whether you want to use the Java or the .NET version. For Java you'll find examples in the user guide: <http://xmlunit.sourceforge.net/userguide/html/ar01s04.html> For .NET you'd use the Validator class. If you feel bold you can try the (currently stuck) XMLUnit 2.0 codebase which already does validation in a very similar way on both platforms. See for example <http://xmlunit.svn.sourceforge.net/viewvc/xmlunit/trunk/xmlunit/src/tests/net-core/validation/ValidatorTest.cs?view=log> for .NET Stefan |
|
From: max m. <beh...@go...> - 2009-11-16 12:53:36
|
Hi guys, Thank you for giving us XMLUnit we like it very much! Now I run into a problem that I hope XMLUnit could also solve. How to validate a Word 2007 XML file against a Schema? Is it possible to use XMLUnit to formulate a Testcase? /behindthevoid |
|
From: Stefan B. <bo...@ap...> - 2009-10-21 19:07:19
|
On 2009-10-20, Tony Rozga <ton...@ni...> wrote: > I'm using XMLUnit primarily for HTMLDocumentBuilder and > TolerantSaxDocumentBuilder (nice tools btw!). Honestly, I would have thought they had been obsoleted by things like tagsoup or jtidy. > If I build a Document from html with in it the String contents > of the Node in question have weird bytes where the space should be. There are way more space characters in Unicode than you'll ever want to know. In particular there is a "non-breaking space" character and I guess this is what you see as "weird bytes". is not a simple space and so you can't expect to get that. Stefan |
|
From: Tony R. <ton...@ni...> - 2009-10-20 22:10:42
|
Hi,
I'm using XMLUnit primarily for HTMLDocumentBuilder and
TolerantSaxDocumentBuilder (nice tools btw!). If I build a Document
from html with in it the String contents of the Node in question
have weird bytes where the space should be. I ran into this trying to
split a resulting string on whitespace.
For example, with <body>test after</body>, the body text string I
get has the following utf-8 bytes:
bytes: 116 101 115 116 -62 -96 97 102 116 101 114
I was expecting to find 32 where the -62 and -96 are. Bug?
I'm using latest version with java 1.6.0.16.
Thanks,
Tony Rozga
Here is a test (not JUnit though :):
import javax.xml.xpath.XPath;
import javax.xml.xpath.XPathConstants;
import javax.xml.xpath.XPathExpression;
import javax.xml.xpath.XPathFactory;
import org.custommonkey.xmlunit.HTMLDocumentBuilder;
import org.custommonkey.xmlunit.TolerantSaxDocumentBuilder;
import org.custommonkey.xmlunit.XMLUnit;
import org.w3c.dom.Document;
import org.w3c.dom.NodeList;
public class XmlUnitBug {
public static void main(String[] args) {
try {
String html = "test after";
TolerantSaxDocumentBuilder tolerantSaxDocumentBuilder = new
TolerantSaxDocumentBuilder(XMLUnit.newTestParser());
HTMLDocumentBuilder builder = new
HTMLDocumentBuilder(tolerantSaxDocumentBuilder);
Document doc = builder.parse(html);
XPathFactory factory = XPathFactory.newInstance();
XPath xpath = factory.newXPath();
XPathExpression expr = xpath.compile("/html/body");
String body = ((NodeList) expr.evaluate(doc,
XPathConstants.NODESET)).item(0).getTextContent();
System.out.println("body: " + body);
System.out.print("bytes: ");
byte[] bytes = body.getBytes("UTF-8");
for (byte b : bytes) {
System.out.print(b);
System.out.print(" ");
}
System.out.println("");
} catch (Exception ex) {
System.out.println("whoops: " + ex);
}
}
}
|