In an OpenCMS environment I have created a link object:
<xsd:sequence>
<xsd:element name="LinkTitle" type="OpenCmsString" minOccurs="1" maxOccurs="1" />
<xsd:element name="InternalLink" type="OpenCmsVfsFile" minOccurs="0" maxOccurs="1" />
<xsd:element name="ExternalLink" type="OpenCmsString" minOccurs="0" maxOccurs="1" />
</xsd:sequence>
This means that LinkTitle is always mandatory. This is correct. Given a LinkTitle, one (and only one) between InternalLink and ExternalLink must be provided. If I set minOccurs="1" for both fields doesn't makes any sense. What can I do?
It should be usefull if I could create two regex (one for InternalLink and one for ExternalLink) and than make an OR (rather than the usual AND) beetween them.
you can use nested XSD option.
refer this link http://arquivo.bng-galiza.org/opencms/opencms/alkacon-documentation/documentation_xmlcontent/step5-nestedcontents.html
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 have multiple XSD files that describe an object. I want to generate the class from these objects so I can parse an XML that and create that object. I used xsd.exe that Visual Studio provides as follows:
xsd /c efreight-CommonReportingSchema-1.0.xsd
../common/efreight-CommonReportingSchemaExtensions-1.0.xsd
../common/UBL-CommonAggregateComponents-2.1.xsd
../common/UBL-CommonBasicComponents-2.1.xsd
../common/UBL-UnqualifiedDataTypes-2.1.xsd
The efreight-CommonReportingSchema-1.0.xsd file :
<!-- ===== Imports ===== -->
<xsd:import namespace="urn:eu:specification:efreight:schema:xsd:CommonReportingSchemaExtensions-1.0" schemaLocation="../common/efreight-CommonReportingSchemaExtensions-1.0.xsd"/>
<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" schemaLocation="../common/UBL-CommonAggregateComponents-2.1.xsd"/>
<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" schemaLocation="../common/UBL-CommonBasicComponents-2.1.xsd"/>
<xsd:import namespace="urn:oasis:names:specification:ubl:schema:xsd:UnqualifiedDataTypes-2" schemaLocation="../common/UBL-UnqualifiedDataTypes-2.1.xsd"/>
<!-- ===== Common Reporting Schema Definition ===== -->
<xsd:element name="CommonReportingSchema" type="CommonReportingSchemaType">
</xsd:element>
<xsd:complexType name="CommonReportingSchemaType">
<xsd:sequence>
<xsd:element ref="cbc:UBLVersionID" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="cbc:CustomizationID" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="cbc:ProfileID" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="cbc:ID" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="cbc:VersionID" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="cbc:TransportExecutionPlanReferenceID" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="crs:SubmissionDate" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="crs:SubmissionTime" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="crs:ReportingParty" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="crs:Consignment" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="crs:TransportMeans" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="cac:DocumentReference" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
The cs file is generated successfully but when I try to parse the object, several errors occur like the following:
error CS0266: Cannot implicitly convert type 'ShipmentStageType[]' to
'ShipmentStageType1[]'. An explicit conversion exists (are you missing
a cast?)
error CS0266: Cannot implicitly convert type
'TransportHandlingUnitType[]' to 'TransportHandlingUnitType1[]'. An
explicit conversion exists (are you missing a cast?)
error CS0266: Cannot implicitly convert type 'ConsignmentType[]' to
'ConsignmentType1[]'. An explicit conversion exists (are you missing a
cast?)
What I see from the errors is that something went wrong in the generation of the class. I think that several classes are declared twice and that's why the '1' is put in the end of the name.
Is there some kind of configuration change that I can use for xsd.exe? Or is the error caused by somewhere else?
Thanks.
I wrote a small script that loops the files and prints their filenames, so i can use:
xsd.exe /c file1.xsd file2.xsd file3.xsd
That should work :)
PS. I know i'm joining late to the party ;)
I need to rig up an XSD schema that will validate files partially. The file structure is:
<Root>
<Node name="core">
<ElementA>String</ElementA>
<ElementB>String</ElementB>
</Node>
<Node name="something unique">
(any number of elements, with unknown names and types)
</Node>
</Root>
My XSD is something like:
<xs:element name="Root">
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:element name="Node">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" />
</xs:sequence>
<xs:attribute name="name" type="xs:string" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
Which is incomplete and not entirely correct, the un-named <xs:element> is invalid.
There are a few nodes that are required, as well as each node having a unique name attribute; this is what I want to validate. The list of names, and the contents of those nodes, is predefined.
The contents of nodes with unknown names is also unknown, and may contain any number of elements with any name and type, but must not have attributes or values themselves.
The part I'm having trouble with is allowing child elements without knowing their names.
Is it at all possible to do something like this with XSD? Is there a way to have a complex type of elements, or anyType, and an attribute?
Edit: It would be just as acceptable to use the <Node> names as the element type, and then simply allow additional elements with unknown names. Either way, I need to allow nodes with unknown name and type.
To allow "child elements without knowing their names" you could use xsd:any; add it as a repeating particle after your specific (known at "design time") content.
<?xml version="1.0" encoding="utf-8"?>
<!--W3C Schema generated by QTAssistant/W3C Schema Refactoring Module (http://www.paschidev.com)-->
<xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="Root">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Node">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="ElementA" type="xsd:string" />
<xsd:element name="ElementB" type="xsd:string" />
</xsd:sequence>
<xsd:attribute name="name" type="xsd:string" use="required" />
</xsd:complexType>
</xsd:element>
<xsd:element name="Extensions" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:any maxOccurs="unbounded" processContents="lax"/>
</xsd:sequence>
<xsd:anyAttribute processContents="lax"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
For this xml:
<elem1 xmlns="http://www.fixprotocol.org/ns/fast/t/1.0">
<elem2>
<elem2/>
</elem2>
</elem1>
I have this schema, which seems to validate fine against w3 schema validation service, and the schema validates the above XML just fine. Sadly, xsd.exe and some other tools report it to be an error. Is that correct? Are circular group refs dissallowed by XML schema? Thanks!
Update: The schema is not mine, can't change it :(
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.fixprotocol.org/ns/fast/t/1.0" xmlns:t="http://www.fixprotocol.org/ns/fast/t/1.0">
<xs:element name="elem1">
<xs:complexType>
<xs:group ref="t:grp1" />
</xs:complexType>
</xs:element>
<xs:group name="grp1">
<xs:sequence>
<xs:group ref="t:grp2" />
</xs:sequence>
</xs:group>
<xs:group name="grp2">
<xs:sequence>
<xs:element minOccurs="0" name="elem2">
<xs:complexType>
<xs:group ref="t:grp1" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:group>
</xs:schema>
It's a legal scheme. Problem is that xsd is trying to traverse all dependencies. The MS version preprocesses scheme and expands all groups. Because of the cyclic dependency such expansion would be infinite so it quits with an error. With the Mono version there are two probable scenarios:
It tries to traverse dependency tree
and ends up in an infinite loop.
It tries to expand all groups and
ends up in an infinite loop.
That is just my guess. I never saw actual source codes of Mono xsd.
This question is being linked with many recent questions that talk about the same problem: circular groups, and Microsoft's xsd.exe, hence I think it should be answered, even though it is quite "old".
The confusion is caused by what qualifies as a circular group. According to section 3.8.6 of the XSD spec:
"Circular groups are disallowed. That is, within the {particles} of a
group there must not be at any depth a particle whose {term} is the
group itself."
Based on the above, your example is not a circular group, since the group itself does not rely on itself as a particle. Your schema is valid.
This is a circular group:
<?xml version="1.0" encoding="utf-8"?>
<xsd:schema xmlns="http://www.fixprotocol.org/ns/fast/t/1.0" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.fixprotocol.org/ns/fast/t/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="elem1">
<xsd:complexType>
<xsd:group ref="grp1"/>
</xsd:complexType>
</xsd:element>
<xsd:group name="grp1">
<xsd:sequence>
<xsd:choice>
<xsd:group ref="grp1"/>
</xsd:choice>
</xsd:sequence>
</xsd:group>
</xsd:schema>
One cannot rewrite a true circular group. However, your example can be rewritten in a couple of ways: the schema below shows an equivalent content model, based on recursive complex types.
<?xml version="1.0" encoding="utf-8" ?>
<!-- XML Schema generated by QTAssistant/XSD Module (http://www.paschidev.com) -->
<xsd:schema xmlns="http://www.fixprotocol.org/ns/fast/t/1.0" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.fixprotocol.org/ns/fast/t/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation xmlns="">Generated from "Set1" under "Release2"</xsd:documentation>
</xsd:annotation>
<xsd:complexType name="grp1">
<xsd:sequence>
<xsd:element minOccurs="0" name="elem2" type="grp1"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="elem1" type="grp1"/>
</xsd:schema>
It is also "entertaining" to see that the following schema actually works with xsd.exe:
<?xml version="1.0" encoding="utf-8"?>
<!--XML Schema generated by QTAssistant/XML Schema Refactoring (XSR) Module (http://www.paschidev.com)-->
<xsd:schema xmlns="http://www.fixprotocol.org/ns/fast/t/1.0" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.fixprotocol.org/ns/fast/t/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:annotation>
<xsd:documentation xmlns="">Generated from "Set1" under "Release2"</xsd:documentation>
</xsd:annotation>
<xsd:element name="elem1">
<xsd:complexType>
<xsd:group ref="grp1"/>
</xsd:complexType>
</xsd:element>
<xsd:group name="grp1">
<xsd:sequence>
<xsd:element minOccurs="0" name="elem2">
<xsd:complexType>
<xsd:group ref="grp1"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:group>
</xsd:schema>
From an XML instance perspective, all three valid schemas are equivalent.
The issue is probably that the tools you are using don't support all possibilities supported by the XML schema spec. Certainly xsd.exe doesn't support everything. The spec is gigantic and it isn't worth providing mappings from everything it supports into a programming language, particularly when some things just don't map very well.
To work around this, you could try to create a set of C# classes that mimic the xml you want to generate and then run xsd.exe on those classes to generate an xsd. There is probably some other XML schema construct that supports what you want.
I don't know about groups but XSD.exe supports circular elements:
<xs:schema elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Class1" nillable="true" type="Class1" />
<xs:complexType name="Class1">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="1" name="Name" type="xs:string" />
<xs:element minOccurs="0" maxOccurs="1" name="child" type="Class1" />
</xs:sequence>
</xs:complexType>
</xs:schema>