The specific assert condition is evaluated differently by Xerces and Saxon validation engine in oxygenxml editor.
I have created a xsd schema (version 1.1) and the corresponded xml test file following the created schema. The xml file is correct according to XMLSpy 2019.
The validation of the test xml file in oxygenxml 21.0 fails if Xerces is used as validation schema.
At the same time the validation is successful if Saxon is used as validation engine.
Has the Xerces implementation issues with such particular assert clause
<xs:complexType>
<xs:sequence>
<xs:element name="scenario" type="Scenario"/>
<xs:element name="year" type="StressYear"/>
<xs:element name="position" type="STACreditPosition" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:assert test="every $pos in ./position satisfies not(($pos/geography lt $pos/preceding-sibling::position[1]/geography) or (($pos/geography eq $pos/preceding-sibling::position[1]/geography) and ($pos/creditAssetClass le $pos/preceding-sibling::position[1]/creditAssetClass)))"/>
</xs:complexType>
I expect that the validation is successful with Xerces engine.
You haven't given us enough information to investigate this fully, but you are giving the processor a difficult job with the expression $pos/geography lt ..., because the evaluation depends on the data type of the geography element. The specification says that the assertion should be evaluated using the typed value of geography (for example xs:integer if that's the way it's defined), but this is quite hard to achieve because the expression is evaluated before validation has been completed. So although the result is well-defined according to the specification, you might get more interoperable results if you avoid relying on this feature of the specification, and do an explicit type conversion:
<xs:assert test="every $pos in ./position satisfies
not(($pos/geography/xs:integer(.) lt $pos/preceding-sibling::position[1]/geography/xs:integer(.)) ..."/>
I have the following in my XML Schema:
<xsd:simpleType name="DECIMAL_TYPE">
<xsd:restriction base="xsd:double">
<xsd:minInclusive value="-100000"/>
<xsd:maxInclusive value="100000"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType name="ANGLE_VALUE_TYPE">
<xsd:restriction base="DECIMAL_TYPE">
<xsd:minInclusive value="0"/>
<xsd:maxInclusive value="360"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:complexType name="ANGLE_TYPE">
<xsd:simpleContent>
<xsd:extension base="ANGLE_VALUE_TYPE">
<xsd:attribute name="UNITS" type="xsd:string" fixed="degrees"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="SPECIAL_ANGLE_TYPE">
<xsd:simpleContent>
<xsd:restriction base="ANGLE_TYPE">
<xsd:maxInclusive value="90" /> <!-- The source of the problem -->
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
This schema is used in a WSDL that I'm using as the basis for a new SoapUI project. However, when I try to import the project, SoapUI gives this error:
There was something wrong with the WSDL you are trying to import:
Source: null
Error: Must be less than or equal to previous maxInclusive
If I change the '90' in the problem line to be equal to '360', the same error appears.
If I remove the line with the comment ("The source of the problem") then SoapUI imports the WSDL just fine. The schema successfully validates in Eclipse, and WSDL2Java runs fine on it.
What, if anything, is wrong with my schema, and what do I need to do to import this to SoapUI? Thank you!
I wonder if your problem is related to the fact that ANGLE_TYPE names ANGLE_BASE_TYPE as its base type, but your schema fragment has no declaration for such a type.
When I change the declaration to name ANGLE_VALUE_TYPE, both Saxon and Xerces tell me the schema document is valid, and once augmented with some element declarations it seems to behave as desired.
I have a wsdl that defines a schema with:
<xsd:schema elementFormDefault="unqualified"
targetNamespace="http://www.xpto.com/xpto">
and the element:
<xsd:element name="insertResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" name="sys_id"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="1" name="table"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="1" name="display_name"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="1" name="display_value"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="1" name="status"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0" name="status_message"
type="xsd:string"/>
<xsd:element maxOccurs="1" minOccurs="0" name="error_message"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
but when i execute the operation and get the response, SoapUI says its invalid:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<insertResponse xmlns="http://www.xpto.com/xpto">
<sys_id>something</sys_id>
<table>something</table>
<display_name>number</display_name>
<display_value>something</display_value>
<status>something</status>
</insertResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The SoapUI message (with lines wrapped for legibility):
line 4: Expected element 'sys_id' instead of
'sys_id#http://www.xpto.com/xpto' here in element
insertResponse#http://www.xpto.com/xpto
If i change the WSDL to include elementFormDefault="qualified", in the schema, the same response is valid.
Why is this response invalid without elementFormDefault="qualified" and what is the correct way to do it?
Also the code generated against this WSDL doesn't like the response either, failing with:
Unmarshalling Error: unexpected element
(uri:\\"http://www.xpto.com/xpto\\", local:\\"sys_id\\"). Expected
elements are <{}table>,<{}display_value>,<{}display_name>,
<{}error_message>,<{}sys_id>,<{}status_message>,<{}status>
(Again, lines wrapped for legibility.)
Using apache-cxf.
Before your question can be answered clearly, some background information appears to be needed.
In XSD, elements declared within a complex type definition are said to be local to that type. (The alternative is to declare them independently, as top-level elements; then they are global or top-level. Not coincidentally, the top-level elements are those whose declarations are at the top level of the schema document, i.e. those which are children of xsd:schema.)
Every element declared in an XSD schema has a name consisting of a namespace name and a local name. As with XML names generally, the namespace name may be null. When the element's name has a non-null namespace name, it is said to be namespace-qualified; when the namespace name is null, by contrast, the element's name is unqualified.
Top-level element declarations take their namespace from the targetNamespace attribute on the enclosing xsd:schema element. Local element declarations, on the other hand, pose a design question: do they go into the target namespace (i.e. should their names be namespace-qualified)? Or should they have unqualified names?
There are two schools of thought on this in the XSD user community, and there were two schools of thought in the responsible WG. Some feel that any element declared in a schema document for namespace foo should be in namespace foo -- after all, one of the functions of a namespace is to tell you where the element comes from, which is a first step toward finding documentation. Others feel that local elements depend on their containing type in just the same way that attributes do -- and local attributes have unqualified names. The one thing both sides agree on is that the other guys are crazy and that no one with two brain cells to rub together could ever actually believe that things should be that way.
The form attribute on local element declarations is used to control whether the local element in question has a qualified name or an unqualified name; unsurprisingly, the two values it can take are qualified and unqualified. The elementFormDefault attribute on the xsd:schema element is used to specify which of those values should be the default value in the current schema document; its value defaults to unqualified, but it is almost always good practice to specify it explicitly, since otherwise some readers will be confused.
With that background information, it's now possible to answer your question: Why is this response invalid without elementFormDefault="qualified" and what is the correct way to do it?
The insertResponse element declared in the schema, being top-level, has the expanded name (http://www.xpto.com/xpto, insertResponse) -- sometimes expanded names are written in the form {http://www.xpto.com/xpto}insertResponse, and apparently sometimes (as illustrated by your error message) in the form insertResponse#http://www.xpto.com/xpto.
When the schema document does not specify elementFormDefault = "qualified", the form of local element names defaults to unqualified. That means the expanded names of the 'sys_id', 'table', 'display_name', and the other local elements all have a null namespace part, so their expanded names are {}sys_id, {}table, {}display_name, etc. But the document you show has the form
<insertResponse xmlns="http://www.xpto.com/xpto">
<sys_id>something</sys_id>
<table>something</table>
<display_name>number</display_name>
...
The default namespace declaration on insertResponse ensures that the name given as 'sys_id' in the first child element is expanded to {http://www.xpto.com/xpto}sys_id, and similarly for the other children. The basic rule of matching for expanded names in pretty much all XML technologies is that an explicit namespace name like {http://www.xpto.com/xpto} does not match the null namespace name {}. So the element name {http://www.xpto.com/xpto}sys_id does not match the element declaration for an element named {}sys_id. An element required by the schema is not found in the instance, and an element is found in the instance which matches nothing in the declaration. So the insertResponse element is invalid.
When the schema document specified elementFormDefault="qualified", the local elements sys_id etc. are namespace qualified. So the expanded name found in the instance document and the expanded name associated with the declaration in the schema are both the same, namely {http://www.xpto.com/xpto}sys_id. All is well, the document is valid, and life is good, or at least as good as it gets when you are working with SOAP.
Bottom line: the creator of the response message and the creator of the schema are not currently in agreement on what the response is supposed to look like. The correct way to do it is for both of them to understand how namespace qualification works in XML and in XSD, and to agree on what form the response should take.
Good luck.
veI am using XSOM in Java to parse an XSD. It's working really well but there's one piece of information from an element that I just can't seem to get hold of - namely the "id" attribute.
One of my elements looks like this :-
<xsd:element name="ACCOUNTTITLE1" minOccurs="0" id="ACCOUNT.TITLE.1" nillable="true">
<xsd:annotation>
<xsd:documentation>ACCOUNT.TITLE.1</xsd:documentation>
<xsd:appinfo>
<hfp:hasProperty name="fielddatatype" value=""/>
<hfp:hasProperty name="fieldname" value="ACCOUNT.TITLE.1"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:maxLength value="35"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
Here I am trying to retrieve the "ACCOUNT.TITLE.1" text stored in the "id" part of the xsd:element.
Any ideas ?
A safe alternative would also to retrieve it from the "xsd:appinfo" section "fieldname" property. However, I can't see how to get hold of that either!
Any help appreciated.
Sarah
This is what I have in my schema section of my WSDL to specify the field has to be comparison operators
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:pattern value="<|>|<=|>=|="/>
</xsd:restriction>
</xsd:simpleType>
SoapUI complains about this part of the WSDL, I tried to set the value to something with non special characters and the WSDL is valid. So I tried to replace that whole long string to be
value=">gt;" and it valid but value="<lt;" is not valid, and value=">" is also not valid. My question is, why does the WSDL validation need > to be double escaped?
The main question is, how to provide a valid less than side within the pattern value.
This might actually be a bug in SoapUI. I tried using the following schema and XML with Apache Xalan (in Java):
Schema:
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.foo.com/"
xmlns:tns="http://www.foo.com/"
elementFormDefault="qualified">
<element name="foo">
<simpleType>
<restriction base="string">
<pattern value="<|>|<=|>=|="/>
</restriction>
</simpleType>
</element>
</schema>
Sample XML:
<foo xmlns='http://www.foo.com/'>></foo>
and it validates fine. When I try this instead:
<foo xmlns='http://www.foo.com/'>abc</foo>
I get the following error, as expected: cvc-pattern-valid: Value 'abc' is not facet-valid with respect to pattern '<|>|<=|>=|=' for type '#AnonType_foo'.
My recommendation is to try using an enum instead. For example:
<simpleType>
<restriction base="string">
<enumeration value="<" />
<enumeration value=">" />
<enumeration value="<=" />
<enumeration value=">=" />
<enumeration value="=" />
</restriction>
</simpleType>
And see if SoapUI likes this better. Hope this helps!
I think I solved my own problem, why would you define in your schema that one of the allowable value is
<xsd:restriction base="xsd:string">
<xsd:pattern value="=|>|>=|<|<=|<>|[Ii][Nn]|[Nn][Oo][Tt] [Ii][Nn]|[Ll][Ii][Kk][Ee]"/>
</xsd:restriction>