XSD namespace "ns2" issue - xsd

I have schema defined in Request.xsd which will refer common.xsd.
I'm expecting the output should come as below
<Request xmlns="http://ws.myref.com/schemas/test"
xmlns="http://ps.myref.com/schemas/2008/Common">
<EmailList>
<Mail>test#gmail.com</Mmail>
</EmailList>
</Request>
But i'm getting extra namespace "ns2" issue. Can anybody help me out to resolve this issue
<ns2:Request xmlns:ns2="http://ps.myref.com/schemas/test"
xmlns="http://ps.myref.com/schemas/Common">
<ns2:EmailList>
<Mail>test#gmail.com</Mail>
</ns2:EmailList>
</ns2:Request>
Request.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" targetNamespace="http://ps.myref.com/schemas/schemas/test"
xmlns="http://ps.myref.com/schemas/schemas/test" xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
xmlns:com="http://ps.myref.com/schemas/Common">
<xsd:import namespace="http://ps.myref.com/schemas/Common" schemaLocation="../schemas/common/common.xsd"/>
<xsd:element name="Request">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="EmailLists" type="com:EmailList" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Common.xsd
<?xml version="1.0"?>
<xsd:schema xmlns="http://ps.myref.com/schemas/2008/Common" elementFormDefault="unqualified"
targetNamespace="http://ps.myref.com/schemas/Common"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<xsd:complexType name="EmailList">
<xsd:sequence>
<xsd:element name="Mail" type="xsd:string" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>

Your expectation is unreasonable in this instance.
Because the type "EmailList" is defined under the namespace http://ps.myref.com/schemas/2008/Common in the common.xsd file, you have no option but to differentiate it in some way when you use the EmailList type in another schema. If you look at request.xsd, you can see that this is exectyly what happens here:
<xsd:element name="EmailLists" type="com:EmailList" />
The com: in this case is a prefix designed to show that the type is defined in another schema and under a different namespace to the one being used.
In the same way, when the xsd validator uses the request.xsd to validate a schema instance, it has to ensure that the EmailList type you are using in your instance is the same EmailList type which is defined in the common.xsd schema, and the only way it can do that is by using the namespace.
Your expectation can therefore be summarized thus:
"I should be able to mix types defined in two different schema definitions freely together without differentiating them and the parser should understand that."
So you should be able to see now how your expectation does not make logical sense.
If you don't want the "ns2:" in there, your only other alternative is to do this:
<Request xmlns"http://ps.myref.com/schemas/test">
<EmailList xmlns"http://ps.myref.com/schemas/test">
<Mail xmlns="http://ps.myref.com/schemas/Common">test#gmail.com</Mail>
</EmailList>
</Request>

Related

Unmarshalling xsd with selective element replacement from another xsd

I am new to working with xsd and jaxb, so if my questions are ignorant, please educate me. Also, if you need any more info, let me know and I will provide what I can.
At our company we are working with xsd sources from a 3rd party. We need to implement a SOAP - Java translation and we have a bunch of .wsdl and .xsd files to work with. We are running into problems with two of the .xsd files. The 3rd party provides a "datatypes.xsd", with a org.hl7.v3 namespace and a "datatypes-extensions-hl7nl.xsd", with a nl.hl7.v3 namespace.
When I unmarshall the xds sources, the resultant .java files get created under a different package, named after their own namespaces: org/hl7/v3 and nl/hl7/v3.
Whereas the 3rd party has intended that, where applicable, the types from "datatypes-extensions.xsd" have precedence and should be generated instead of those in "datatypes.xsd", and in the same package.
What I have tried so far
Since I cannot alter the xsd sources, I have (unsuccessfully) tried 2 things using a .jxb file.
1: generating the .java files in a single directory. This led to overwriting issues.
2: providing a binding to point to the correct type:
<jaxb:bindings schemaLocation="../coreschemas/datatypes.xsd">
<jaxb:bindings node="//xs:complexType[#name='TEL']">
<jaxb:class ref="nl.hl7.v3.TEL"/>
</jaxb:bindings>
</jaxb:bindings>
This worked initially, until I changed the reference of a supertype, at which point the compiler complained it could no longer locate the proper supertype for the extending types.
Sources
The sources are opensource so if you'd like to see them for yourself: https://decor.nictiz.nl/pub/vzvz/kz-vzvz-xml-20190122T131422.zip
The .wsdl:
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:hl7="urn:hl7-org:v3"
targetNamespace="urn:hl7-org:v3"
name="OpvragenOverdrachtconcerns">
<documentation> WSDL implementatie van OpvragenOverdrachtconcerns</documentation>
<types>
<xsd:schema targetNamespace="urn:hl7-org:v3" elementFormDefault="qualified">
<xsd:include schemaLocation="../schemas_codeGen/REPC_IN990110NL.xsd"/>
</xsd:schema>
<xsd:schema targetNamespace="urn:hl7-org:v3" elementFormDefault="qualified">
<xsd:include schemaLocation="../schemas_codeGen/REPC_IN990111NL.xsd"/>
</xsd:schema>
</types>
<message name="REPC_IN990110NL">
<part name="body" element="hl7:REPC_IN990110NL"/>
</message>
<message name="REPC_IN990111NL">
<part name="body" element="hl7:REPC_IN990111NL"/>
</message>
The header of response message type: REPC_IN990111NL:
<?xml version="1.0" encoding="UTF-8"?>
<!-- REPC_IN990111NL - Opleveren overdrachtconcerns --><!--Note: this file was generated. DO NOT EDIT HERE.--><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:hl7-org:v3"
targetNamespace="urn:hl7-org:v3"
elementFormDefault="qualified">
The header and definition of a conflicting type in datatypes.xsd:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:hl7="urn:hl7-org:v3" xmlns:hl7nl="urn:hl7-nl:v3"
xmlns:sch="http://www.ascc.net/xml/schematron" elementFormDefault="qualified" targetNamespace="urn:hl7-org:v3" xmlns="urn:hl7-org:v3">
<xsd:include schemaLocation="voc.xsd"/>
<xsd:import namespace="urn:hl7-nl:v3" schemaLocation="datatypes-extensions-hl7nl.xsd"/>
<xsd:complexType name="TEL">
<xsd:complexContent>
<xsd:extension base="URL">
<xsd:sequence>
<xsd:element name="useablePeriod" type="IVL_TS" minOccurs="0"
maxOccurs="unbounded">
<!-- FIXME: one would expect the name "GTS" here but it's not
SXCM does ALL the right things, it's just not the right NAME. -->
</xsd:element>
<xsd:element name="id" type="II" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="use" type="set_cs_TelecommunicationAddressUse" use="optional">
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
The header and type in datatypes-extension-hl7nl.xsd
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns:hl7="urn:hl7-org:v3" xmlns="urn:hl7-nl:v3" xmlns:sch="http://purl.oclc.org/dsdl/schematron" targetNamespace="urn:hl7-nl:v3">
<xsd:import schemaLocation="datatypes.xsd" namespace="urn:hl7-org:v3"/>
<xsd:complexType name="TEL">
<xsd:complexContent>
<xsd:extension base="ANY">
<xsd:sequence>
<xsd:element name="useablePeriod" type="QSET_TS" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="value" type="xsd:anyURI" use="optional"/>
<xsd:attribute name="use" type="set_TelecommunicationAddressUse" use="optional"/>
<xsd:attribute name="capabilities" type="set_TelecommunicationCapability" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
Expected and actual results
As stated above, instead of generating two packages according to the different namespaces, one should be created with the "nl.hl7.v3" types being generated intead of the "org.hl7.v3" ones with the same name.
Thank you for your time in advance.
Max

Unmarshal Jaxb class error

I have a xml string which is a response from third party server.
<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<GetRateQuoteResponse>
<GetRateQuoteResult>
</GetRateQuoteResult>
</GetRateQuoteResponse>
</SOAP-ENV:Body></SOAP-ENV:Envelope>
I want to parse it in JAX-WS.
So i converted this String to xsd file using this web site
The web site gave me the xsd as follows.
<?xml version="1.0" encoding="utf-16"?>
<xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="SOAP-ENV:Envelope">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="SOAP-ENV:Body">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="GetRateQuoteResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="GetRateQuoteResult" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
I now generate JaxB classes from this xsd, it tries to create class named
SOAP-ENV:Envelope and SOAP-ENV:Body which is invalid name for a class and it fails to do so.
Also even if i modify xsd to Envelope and Body the Unmarshalling fails.
javax.xml.bind.UnmarshalException: unexpected element (uri:"http://schemas.xmlsoap.org/soap/envelope/", local:"Envelope"). Expected elements are <{}SOAP-ENV:Envelope>
Please guide.
The XSD should not contain any SOAP elements; only the WSDL does. The XSD by definition is or data only. The transport protocol information (SOAP) should not be in the data definition as XSDs have applications outside of SOAP.
Omit the SOAP schema elements from the entry you pass to the XSD generato. By including that stuff in there, you're indicating to the generator that those elements will be part of your JAXB-generated classes (which shouldn't be the case). What you should feed the generator is the excerpt below, which would rightly generate the GetRateQuoteResponse-containing schema
<GetRateQuoteResponse>
<GetRateQuoteResult>
</GetRateQuoteResult>
</GetRateQuoteResponse>
The result:
<?xml version="1.0" encoding="utf-16"?>
<xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="GetRateQuoteResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="GetRateQuoteResult" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>

How to define an 'any element' with mandatory attributes

I have an XML which can have any element such as:
<AnyElements>
<Any1 id="any1" />
<Any2 id="any2" />
...
</AnyElements>
But id attribute is mandatory.
How can i define such a xsd?
<xs:element name="AnyElements" type="AnyRootType" />
<xs:complexType name="AnyRootType">
<xs:sequence>
<xs:any type="AnyChildType" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AnyChildType">
<xs:attribute ref="id" use="required"/>
</xs:complexType>
<xs:attribute name="id" type="xs:string"/>
It all depends on how you're going to define the processing model. Here are some things you need to consider first.
An any particle can't be constrained with a type. It comes with an attribute named processContents that could be skip, lax, and the default, strict. Once you understand exactly what it means, then going with skip simply means that you will not be able to enforce your mandatory attribute - the processor will do just that, "skip". If you set it lax, then it will process it only if the XSD describing the content is actually available, otherwise it'll skip; The third option strict, requires the XSD describing this extra content to be available - period.
So the any particle can be made to work only if the XSD describing the "any" is available during validation. The option I have in mind is kind of limiting, but it has the advantage of being the closest to the "spirit" of an any in that it wouldn't have to derive from a particular base type, or reference some atttributes; for this, a key constraint similar to would approximate your requirement:
<xsd:key name="ofid">
<xsd:selector xpath="*"/>
<xsd:field xpath="#id"/>
</xsd:key>
In effect, the key makes the attribute required. The downside may be that each value must be unique, too. Maybe with an attribute named id , it is expected; if instead you wish to apply the pattern to something such as age, then it wouldn't work.
If you decide that having XSDs available at runtime is acceptable, then other alternatives may include use of abstract elements or elements with abstract types. The good thing is that it'll bring a more disciplined approach (you'll set the constraints clearly right from the beginning), and without placing uniqueness of values constraints. The downside could be that it creates coupling to another XSD which describes the "contract" - your mandatory attributes.
UPDATE: As per your comment, below is an alternative based on substitution groups. I tried to keep as much as possible your old XSD components names.
Contract.xsd: This has the components of your contract. It basically describes the head of your substitution group; it indicates the need for an id attribute.
<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="AnyChildType" abstract="true">
<xsd:attribute name="id" use="required"/>
</xsd:complexType>
<xsd:element name="AnyElement" abstract="true" type="AnyChildType"/>
</xsd:schema>
GenericInstance.xsd: It describes the root of your "generic" document. It "integrates" your contract in the context of your defined root element.
<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:include schemaLocation="Contract.xsd"/>
<xsd:element name="AnyElements" type="AnyRootType"/>
<xsd:complexType name="AnyRootType">
<xsd:sequence>
<xsd:element ref="AnyElement" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
SpecificInstance1.xsd: A particular contract.
<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:include schemaLocation="Contract.xsd"/>
<xsd:element name="SomeElement1" substitutionGroup="AnyElement">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="AnyChildType">
<xsd:annotation>
<xsd:documentation>Any content goes.</xsd:documentation>
</xsd:annotation>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
SpecificInstance2.xsd: Another contract (shows a different authoring style).
<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:include schemaLocation="Contract.xsd"/>
<xsd:element name="SomeElement2" substitutionGroup="AnyElement" type="SomeElement2Type"/>
<xsd:complexType name="SomeElement2Type">
<xsd:complexContent>
<xsd:extension base="AnyChildType">
<xsd:annotation>
<xsd:documentation>Any content goes.</xsd:documentation>
</xsd:annotation>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
Visually this is how they're tied together. You can see that the coupling between XSDs is maintained at minimum.
A sample XML, valid in the scope defined by your generic instance, and the specific ones.
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!-- Sample XML generated by QTAssistant (http://www.paschidev.com) -->
<AnyElements xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SomeElement1 id="1"/>
<SomeElement2 id="1"/>
</AnyElements>
If you're limited to validate your XML using one XSD only, below would be an XSD just for that:
<?xml version="1.0" encoding="utf-8" ?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:include schemaLocation="GenericInstance.xsd"/>
<xsd:include schemaLocation="SpecificInstance1.xsd"/>
<xsd:include schemaLocation="SpecificInstance2.xsd"/>
</xsd:schema>
I've tested the above with XSD 1.0 running on .NET; having the ability to run on XSD 1.1 or particular features in other XSD processors would invalidate some of what I've said.

Xml Schema with AnyAttribute, add attribute to specific element

If I have two elements with the <anyattribute/> element in my schema like this:
<xs:element name="NodeType1">
<xs:complexType>
<xs:anyAttribute />
</xs:complexType>
</xs:element>
<xs:element name="NodeType2">
<xs:complexType>
<xs:anyAttribute />
</xs:complexType>
</xs:element>
Is it possible to extend only one of those elements in another schema? Let's say I wanted to add an attribute to NodeType2 only.
Elements are not extensible; in general, you will have to create a named (global, under the schema element) type if you wish to use as a base for extension anywhere else, be that in the same or another XML Schema.
Your question is very interesting because it really makes one wonder what is the purpose of extending something that by definition could match anything, anyhow. For that, the effect of the extension is really the opposite; it creates a constraint for the attribute(s) named in the extension.
So, the first XSD:
<?xml version="1.0" encoding="utf-8" ?>
<!--W3C Schema generated by QTAssistant/W3C Schema Refactoring Module (http://www.paschidev.com)-->
<xsd:schema targetNamespace="http://tempuri.org/XMLSchema.xsd"
elementFormDefault="qualified"
xmlns="http://tempuri.org/XMLSchema.xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="root" type="BaseType"/>
<xsd:complexType name="BaseType">
<xsd:anyAttribute processContents="lax" />
</xsd:complexType>
<xsd:complexType name="Extending">
<xsd:complexContent>
<xsd:extension base="BaseType">
<xsd:attribute name="new1" type="xsd:int"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
With this schema, the following sample XML is perfectly valid:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!-- Sample XML generated by QTAssistant (http://www.paschidev.com) -->
<root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" new1="S" new2="2" xmlns="http://tempuri.org/XMLSchema.xsd"/>
Now, if I'm changing
<xsd:element name="root" type="BaseType"/>
to
<xsd:element name="root" type="Extending"/>
the same sample XML if no longer valid:
Error occurred while loading [], line 3 position 61
The 'new1' attribute is invalid - The value 'S' is invalid according to its datatype 'http://www.w3.org/2001/XMLSchema:int' - The string 'S' is not a valid Int32 value.
Changing the S to a numeric, it will make the XML valid.
Isn't that a funny thing about "extending"?...

XJC Generating Integer Instead of int

The following schema should be generating two primitive int fields in a Value class, but instead generates a primitive int for the element and java.lang.Integer for the attribute.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema version="1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com/test" xmlns:test="http://www.example.com/test"
elementFormDefault="qualified">
<xsd:element name="values">
<xsd:complexType>
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="test:value" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="value">
<xsd:complexType>
<xsd:sequence>
<!-- Is generated as primitive int -->
<xsd:element name="element" type="xsd:int" />
</xsd:sequence>
<!-- Is generated as java.lang.Integer -->
<xsd:attribute name="attribute" type="xsd:int" />
</xsd:complexType>
</xsd:element>
</xsd:schema>
I've looked through the JAXB documentation for anything that says that attributes and elements may be generated differently and found nothing.
Can anyone explain this? Is there a fix to make the attribute generate as a primitive int?
I'm not entirely sure this is the answer, but I had an epiphany while debugging my app.
The default multiplicity for an element in an XML schema is 1..1 (required) where as the default multiplicity for an attribute is 0..1 (optional).
So, since the element is required and a primitive in Java has a default value (most likely 0), it makes sense to generate an <xsd:element type="xsd:int" /> as a Java primitive.
Since the attribute is optional there is a possibility that it may be nillable which would not be possible using a primitive. The java.lang.Integer is an Object and thus allowed to be null, so it makes sense to generate an <xsd:attribute type="xsd:int" /> as an java.lang.Integer.
If you make an attribute be required (<xsd:attribute type="xsd:int" use="required" />), it will generate as a primitive int. I haven't seen documentation by JAXB that explicitly says this, but that doesn't mean it doesn't exist; perhaps I just missed it.

Resources