How can I remove the below warning in the xsd. mymain.xsd refers to mysecond.xsd
my main.xsd
<?xml version="1.0" encoding="UTF-8"?><xsd:schema elementFormDefault="qualified" targetNamespace="http://abc.com" version="2.0" xmlns:tyu="http://abc.com" xmlns:my="def.com" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="def.com" schemaLocation="mysecond.xsd"/>
<xsd:complexType name="myType">
<xsd:complexContent>
<xsd:restriction base="my:myType">
<xsd:sequence>
<xsd:element minOccurs="0" name="rty" type="tyu:myagainType"/>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="myagainType">
<xsd:complexContent>
<xsd:restriction base="my:myagainType">
<xsd:sequence>
<xsd:element minOccurs="1" name="uid">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="1"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
</xsd:sequence>
</xsd:restriction>
</xsd:complexContent>
</xsd:complexType>
</xsd:schema>
mysecond.xsd
<?xml version="1.0" encoding="UTF-8"?><xsd:schema elementFormDefault="qualified" targetNamespace="def.com" version="2.0" xmlns:my="def.com" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="myagainType">
<xsd:sequence>
<xsd:element minOccurs="0" name="klo" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="myType">
<xsd:sequence>
<xsd:element minOccurs="0" name="rty" type="my:myagainType"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
warning
Warning 1 Invalid particle derivation by restriction - 'Derived element 'http://abc.com:rty' is not a valid restriction of base element 'def.com:rty' according to Elt:Elt -- NameAndTypeOK.'. D:\files\mymain.xsd 3 4
Short answer, you cannot. To begin with, your rty in mySecond.xsd is locally defined and qualified and in a different namespace than the "equivalent" rty in the main.xsd, the latter also locally defined and qualified in a different namespace.
If you go through the XML Schema spec, part 2, you'll get an explanation for each rule that applies to a valid restriction. In your case, you either use the same named element (start by "unqualifying" the rty element), or a member of a substitution group.
You obviously don't want the same element, since it'll give you the same content model - you have one element only. One reason people use restriction is to reduce the content model (remove elements from the list) and/or fiddle with min/maxOccurs for particles.
You can't do things using substitution groups since you defined rty locally; the head of a substitution group must be defined globally.
To allow for what you want, you have to completely rewrite your XSD. A better description around what exactly you're trying to achieve along with any constraints you place on XSD authoring (e.g. use of substitution groups, or redefine, or the context in which your XSDs will be used) may help others provide you with better answers.
Related
I have a question about backward compatibility of a Webservice interface in context of choices in output message. Couldn't really find an answer to that.
Let's assume I have a Webservice with an operation "getData" which has the following response message (this is V1 of the Webservice). The response message includes a choice element which gives back either the payload of "Instruction" or "KeyTranslation". This V1 WSDL is used by various consumer which are generating the java bindings and rolling out the application in production.
<xsd:complexType name="GetInstructionListResponse">
<xsd:sequence>
<xsd:element name="ContinueInfo" type="tns:ContinueInfo" form="qualified" />
<xsd:element name="ResultLength" type="xsd:integer" form="qualified" />
<xsd:element name="Payload">
<xsd:complexType>
<xsd:choice>
<xsd:element name="DataObjectList1" type="tns:Instruction" form="qualified" minOccurs="1" maxOccurs="50" />
<xsd:element name="DataObjectList2" type="tns:KeyTranslation" form="qualified" minOccurs="1" maxOccurs="50" />
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="ReturnCodeList" type="tns:ReturnCodeList" form="qualified" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Description: List of error descriptions</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
As a provider of this interface we would introduce now a third choice element "Advise" after the rollout of V1.
<xsd:complexType name="GetInstructionListResponse">
<xsd:sequence>
<xsd:element name="ContinueInfo" type="tns:ContinueInfo" form="qualified" />
<xsd:element name="ResultLength" type="xsd:integer" form="qualified" />
<xsd:element name="Payload">
<xsd:complexType>
<xsd:choice>
<xsd:element name="DataObjectList1" type="tns:Instruction" form="qualified" minOccurs="1" maxOccurs="50" />
<xsd:element name="DataObjectList2" type="tns:KeyTranslation" form="qualified" minOccurs="1" maxOccurs="50" />
<xsd:element name="DataObjectList2" type="tns:Advice" form="qualified" minOccurs="1" maxOccurs="50" />
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="ReturnCodeList" type="tns:ReturnCodeList" form="qualified" minOccurs="0">
<xsd:annotation>
<xsd:documentation>Description: List of error descriptions</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Question is now, is this change in the output message a breaking change, i.e does an existing consumer (working with V1 which doesn't require the new choice element) has to do anything (e.g. to regenerate the java bindings, any marshalling problems?) in case we would replace as a provider the V1 WSDL provider interface with this extended response structure or would that be transparent for him as long he doesn't require the third choice element in its processing?
By a strict definition, I would call this a breaking change. By "strict", I mean that it's possible to write a program which will work before the change, and break after the change. Any program that would have received one of the two original choices before the change, but now will receive the third choice - this program will be broken.
Furthermore, any program which can read the WSDL will see that it changed. Such a program could reasonably be permitted to "break" if the WSDL changes.
Keep in mind that, when using a tool like wsdl2java or "Add Service Reference" in Visual Studio, code is being written from the WSDL. A change in the WSDL will result in a change in the generated code. Don't take it lightly that you could be changing someone's code without their knowledge.
In the meantime I was setting up a test bed (Eclipse, ApacheV6, Axis2) and was running a test:
Having a client which was using WSDL java bindings of V1 of the server (two choice elements)
Having a server running with WSDL V2 implementation having three choices.
Result: Java client could still connect and getting correct results for the two choice elements back from the V2 server (no marshalling problem, no recompile necessary).
I am working with an xsd, trying to get it to validate an xml.
The xml is used to create objects. There are two types of objects that can be created by the elements in the list: SC and SMSC. SMSC is an SC, and extends it.
SMSC doesn't contain any new properties. From the perspective of the xml, an SMSC is identical to an SC in every way, except that the elements that define its properties are wrapped by <SMSC> tags instead of <SC> tags.
Our XSD looks like this:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name='Definitions'>
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="unbounded" name="SC">
<!--SNIP properties of SC and SMSC -->
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
Is there a way to change this to allow either SC or SMSC as the element, other than duplicating all of the property definitions in an SMSC element? We don't want to have to double the length of the document and duplicate all of the property definitions.
As it stands, the only validation error we have in our XML is where we have an SMSC element. If there isn't a way to fix this without duplicating all the property definitions we'll leave it as-is, but we'd obviously prefer to eliminate the warning this throws if practical.
While it is confusing by tags instead of tags, I would think that below is either answering your question, or elicits better explanations.
So, what you see is avoiding duplication; you don't actually need the additional type SMSC (see Definitions2), but I've put it just in case (Definitions). Making the SMSC element of the SC type would work exactly the same.
The difference between Definitions / Definitions2 and Definitions3 is that one uses substitution groups instead of choices. I personally prefer substitution groups to choices, yet is not that uncommon to run into issues related to substution groups (i.e. they are poorly supported here and there).
<?xml version="1.0" encoding="utf-8" ?>
<!-- XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com) -->
<xsd:schema targetNamespace="http://tempuri.org/XMLSchema.xsd" xmlns="http://tempuri.org/XMLSchema.xsd" elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:complexType name="SC">
<xsd:sequence>
<!-- Stuff goes here -->
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="SMSC">
<xsd:complexContent>
<xsd:extension base="SC"/>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="Definitions">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="SC" type="SC"/>
<xsd:element name="SMSC" type="SMSC"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<!-- Another way -->
<xsd:element name="Definitions2">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="SC" type="SC"/>
<xsd:element name="SMSC" type="SC"/>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="Definitions3">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="SC" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="SC" type="SC" />
<xsd:element name="SMSC" type="SMSC" substitutionGroup="SC" />
</xsd:schema>
I need to create an XSD which would validate the following type of XML:
<dbengine stylesheet="file:transformation.xslt">
<queries>
<query name="update" inputtype="file">file:/src/test.sql</query>
<query name="update" inputtype="sql">select * from test</query>
</queries>
</dbengine>
This can be done by formulating the following schema:
<xsd:element name="dbengine">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="queries" type="queries" minOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="stylesheet" type="xsd:string" use="optional"/>
</xsd:complexType>
</xsd:element>
Additionally, I need this tag to be able to receive and send messages from/to a channel by extending inputOutputEndpointType from http://www.springframework.org/schema/integration/spring-integration-1.0.xsd. So ideally I should have something like this:
<xsd:element name="dbengine">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="int:inputOutputEndpointType" >
<xsd:sequence>
<xsd:element name="queries" type="queries" minOccurs="1"/>
</xsd:sequence>
<xsd:attribute name="stylesheet" type="xsd:string" use="optional"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
However this results in an error (in the eclipse editor):
cos-ct-extends.1.4.3.2.2.1.a: The content type of a derived type and
that of its base must both be mixed or both be element-only. Type
'#AnonType_dbengine3' is element only, but its base type is not.
Adding the mixed="true" attribute doesn't help and every other attempt of solving this failed so far.
I tried your schema in my XML Schema editor and I did not get any error for your snippet (I had to put it within an xsd:schema, and add a dummy definition for the queries complex type).
I think you're simply experiencing an issue with the Eclipse editor. The living proof is in the same file, please take a look at the "innerEndpointDefinitionAware" complexType.
One thing you should try with Eclipse is to actually download spring-integration-1.0.xsd, spring-beans-2.0.xsd and sprint-tool-2.0.xsd in the same folder. Edit the integration file to make sure that for the xsd:imports you manually add the schemaLocation to the files you've downloaded. Try again and see what happens. If it works, the issue is then related to the "dangling" approach used by almost all of the Spring schemas (use of xsd:import without the schemaLocation). With dangling definitions, it is up to the schema processor (in your case provided by Eclipse) to resolve those namespaces.
With my editor it worked even without downloading, after I've configured it to resolve the dangling definitions to the appropriate versions of the beans and tools - maybe Eclipse supports the same?
I couldn't find a way to implement it, here my workaround. I just created a new complexType which substitutes spring inputOutputEndpointType.
<xsd:complexType name="workaround">
<xsd:attribute name="output-channel" type="xsd:string">
<xsd:annotation>
<xsd:appinfo>
<tool:annotation kind="ref">
<tool:expected-type type="org.springframework.integration.core.MessageChannel" />
</tool:annotation>
</xsd:appinfo>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="input-channel" type="xsd:string">
<xsd:annotation>
<xsd:appinfo>
<tool:annotation kind="ref">
<tool:expected-type type="org.springframework.integration.core.MessageChannel" />
</tool:annotation>
</xsd:appinfo>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="order" type="xsd:string">
</xsd:attribute>
<xsd:attribute name="auto-startup" type="xsd:string" />
</xsd:complexType>
in the dbengine tag I extend this complexType:
<xsd:extension base="workaround" >
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.
I have a XSD file that is to be parsed and converted into a XML file.
Is there any way to do it using Perl ??? After xml file is generated, i have to parse that xml file which is the second part, but i was struck in the first part of converting the XSD file to XML format.
XSD is given below
<?xml version="1.0" encoding="UTF-8"?>
<!-- This document was generated by the Objective Systems ASN2XSD Compiler
(http://www.obj-sys.com). Version: 6.3.0, Date: 06-May-2010. -->
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.obj-sys.com/S1AP-PDU-Descriptions"
targetNamespace="http://www.obj-sys.com/S1AP-PDU-Descriptions"
xmlns:S1AP-CommonDataTypes="http://www.obj-sys.com/S1AP-CommonDataTypes"
xmlns:S1AP-PDU-Contents="http://www.obj-sys.com/S1AP-PDU-Contents"
xmlns:S1AP-Constants="http://www.obj-sys.com/S1AP-Constants"
xmlns:asn1="http://www.obj-sys.com/v1.0/XMLSchema"
elementFormDefault="qualified">
<xsd:import namespace="http://www.obj-sys.com/S1AP-CommonDataTypes"
schemaLocation="S1AP-CommonDataTypes.xsd"/>
<xsd:import namespace="http://www.obj-sys.com/S1AP-PDU-Contents"
schemaLocation="S1AP-PDU-Contents.xsd"/>
<xsd:import namespace="http://www.obj-sys.com/S1AP-Constants"
schemaLocation="S1AP-Constants.xsd"/>
<xsd:import namespace="http://www.obj-sys.com/v1.0/XMLSchema"
schemaLocation="http://www.obj-sys.com/v1.0/XMLSchema/asn1.xsd"/>
<!-- PDU definition -->
<xsd:element name="s1AP-PDU" type="S1AP-PDU"/>
<xsd:complexType name="S1AP-PDU">
<xsd:choice>
<xsd:element name="initiatingMessage" type="InitiatingMessage"/>
<xsd:element name="successfulOutcome" type="SuccessfulOutcome"/>
<xsd:element name="unsuccessfulOutcome" type="UnsuccessfulOutcome"/>
<xsd:any namespace="##other" processContents="lax"/>
</xsd:choice>
</xsd:complexType>
<xsd:complexType name="InitiatingMessage">
<xsd:sequence>
<xsd:element name="procedureCode" type="S1AP-CommonDataTypes:ProcedureCode"/>
<xsd:element name="criticality" type="S1AP-CommonDataTypes:Criticality"/>
<xsd:element name="value" type="asn1:OpenType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="SuccessfulOutcome">
<xsd:sequence>
<xsd:element name="procedureCode" type="S1AP-CommonDataTypes:ProcedureCode"/>
<xsd:element name="criticality" type="S1AP-CommonDataTypes:Criticality"/>
<xsd:element name="value" type="asn1:OpenType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="UnsuccessfulOutcome">
<xsd:sequence>
<xsd:element name="procedureCode" type="S1AP-CommonDataTypes:ProcedureCode"/>
<xsd:element name="criticality" type="S1AP-CommonDataTypes:Criticality"/>
<xsd:element name="value" type="asn1:OpenType"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
It looks like you used one of the free tools from Objective Systems to convert some ASN.1 data. I believe that you used their tool, ASN2XSD, when you meant to use their ASN2XML tool instead. The XSD tool produces a description document like the one you show in your question that helps another tool format and describe your data, which is not what you wanted.
If you use their ASN2XML tool from the first link above to convert your ASN.1 data, it will produce the XML output you need without losing any data. You can then use Perl's XML tools to parse that data.