how to skip few element validations in xsd in java - java

I am trying to validate an xml against an xsd in java.
In XSD one of the field(tax_id) is defined as manadatory element.
But in my scenario I pass an xml to another component, that component fills the manadatory
field(tax_id).
Before sending that xml to the next component, I have to validate that xml against the xsd.
As, in that XSD element tax_id is defined as mandatory element, I get exception for not filling mandatory element (tax_id).
I can create a new xsd by making tax_id as optional field, but with this we would be having 2 xsds.
Is there any way to skip/ignore few elements while validating in java?

In general, no. The purpose of the XSD is to specify the rules that the document must meet, in order to be valid. You can't ignore or skip some of those rules. If you could, you'd probably have other problems. For example, if required elements were really optional (or could be) then technically any element that was supposed to contain a bunch of other elements could be empty (and still valid) under that more lax validation.
In your situation, you probably have two options:
Change your workflow - make sure the first component populates the XML with the empty tax_id. Then it will validate.
Introduce a second schema - one earlier in the "pipeline" of processing, that doesn't require tax_id. Then validate against that.

Related

Does XMLUNIT provide option to ignore certain elements in XML's for comparison?

I am wondering if XMLUNIT provides a way to ignore some of the elements present in the XML before doing the comparison.For example, if I want to ignore field which is randomly generated by the server.Is there anything available out of the box in XMLUnit to ignore certian elements or I need to write a custom DifferenceListener ?
Also, does it provide the elements name that do not match? If not, then what could be the best way to compare two XML which can allow me to ignore some elements and also provide me the elements names/values that does not match?
I'm afraid a custom DifferenceListener is the only way to go right now. There is a feature request for XMLUnit2 (https://github.com/xmlunit/xmlunit/issues/26) that hasn't been implemented, yet.
Implementing the DifferenceListener may be a bit cumbersome since you'll not only receive Differences for the elements you want to ignore but most likely also receive them for the number of children of the parent element.
Each Difference contains NodeDetails for the nodes seen on the test and control side and the NodeDetail contains the DOM Node (which will be an Element in your case).

Soap: How to validate empty elements

How is it possible to validate that an element in a Soap-Request must exist and must contain a value?
I have a webservice that receives Soap requests which contain mandatory-values. These values must not be empty and must exist in the xml-document.
If I use
#XmlElement(nillable=false, required=true)
to achieve that, I can validate that the element must exist and that it may not be empty if the element has the attribute
xsi:nil="true"
But what if the client does not add the nil-attribute and just send an empty element like
<element/>
How can I define that this is forbidden? In other words: How can I define that only elements like
<element>value</element>
are allowed?
Thanks!
JAXB facets claims to that
the generated WSDL file describing the service interface will contain
an XSD declaration
that was defined with annotations.
If you're using code first approach, you could generate WSDL and deploy your WS, instead of leaving WSLD generation for JAX-WS runtime.

jaxb umarshalling problem: can not get the attributes on empty xml tags

I have to unmarshal a xml-soap string to a Java object using JAXB. The XML contains a lot of empty tags with filled attributes, for instance most information in the message is relayed as follows:
<ID code="123" codeSystem="12.12.12"/>
I am interested in the attributes.
Problem:
If I inspect the object after the unmarshalling, all the empty tags (like the one above) have no representation (e.g. are null) in the Java object. Only the filled tags (e.g. 123 have been added to the Java object.
Maybe this behaviour is conform xml standards, but I am still interested in the attributes.
Can someone tell me if there is a way to get the attributes??
Possible workaround: to give each element a default value ("") when its null by binding it to an adapter using the bindings-file. But I only succeeded in doing this for simple-types.
Used versions: we are using the jaxb implementation in Java 1.6
Many thanks.
Wybrand.
As there is no default value for XML attributes I would implement the initialization code in the afterUnmarshal method. There you could check all attributes you are interested in and set them to a valid non-null value.
For details how to use afterUnmarshal see: How can I have JAXB call a method after it has completed unmarshalling an XML file into an object?
I solved the problem. But the problem was not JAXB.
The party which sends the xml which I have to umarshall puts a 'null namespace' in the element declaration.
Xml fragment:
The id element has in its declaration xmlns="". (I presume this is a bug) and the root tag has the declaration xmlns:ns3="urn:hl7-org:v3"
For this reason (I think) the jaxb unmarshaller does not see the id element as part of the message.

Ignore element order while validating XML against XSD

We have an XML which needs to be validated against an XSD. The XML is being generated by XSTREAM. and We are using jaxp api's to validate the XML against the respective XSD. Unfortunately, currently our test case fail as the generated XML has elements/Tags in different order/sequence than the XSD.
Is it possible to ignore the order of elements in generated XML while validating it against XSD?
Thanks for the help in advance.
What you are asking for is a way to say "validate some of the XSD and ignore other parts". I don't think that can be done.
One possible solution would be to modify the schema so that instead of using a <sequence> for those elements (which requires that the elements be in a particular order) you can use <all>, which allows the elements to be in any order.
The point of a schema is to impose certain structure and requirements on an XML document. You can't just say "eh, I don't like that particular part of the schema, ignore it" as then the document doesn't conform to the schema anymore.

Duplicate namespace declarations in JAXB generated XML

I am using JAXB to generate XML from Java objects, it's a realtime, quite high message rate application and works fine most of the time. However occassionally and without any obvious clues as to why, I am getting duplicate namespace declarations in the generated XML. eg:
<UpdateRequest xmlns="http://xml.mycomp.com/ns/myservice"
xmlns="http://xml.mycomp.com/ns/myservice">
<field1>value</field1>
...
</UpdateRequest>
Has anyone seen this behaviour before?
Check if the xsd code of this class allow the creation of more than 1 instance of the repeated attribute. if so, you can avoid this repetitions setting the number of instances of the xmlns attribute for each UpdateRequest object.
If the problem is your code (maybe there is being created this attribute twice) and you have limited the number of instances of the attribute (as i said above), the program will show an error at runtime complaining that you are trying to insert an attribute already defined.
A solution might be available at this link.
here's the relevant section quoted verbatim from the above link that may be relevant for you:
Similar explicit inclusion of a schema
type in an instance document's element
occurs if you instantiate a JAXB
element using an object of some
(abstract) XML schema base type so
that the element would have the
element tag of the base type.
Second, avoid xs:anySimpleType since
this will also create multiple
references to the namespaces bound to
xsi and xs, and type attributes
containing the actual type. And you
lose JAXB's advantage of having typed
fields in your Java classes so that
you lose all the checks the Java
compiler might do, and for
unmarshalling you'll have to handle
all the conversions yourself.

Categories