I'm working with a web service from an external company, which has defined the following restriction to an element in their wsdl:
<xs:simpleType>
<xs:restriction base="xs:positiveInteger">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="9999999999"/>
</xs:restriction>
</xs:simpleType>
Doing the conversion of this restriction in a class, I created a property with the tipe UInt32, but this data type only allows numbers up to 4294967295, very lower than the maxInclusive defined in the restriction.
This kind of restriction is technically and logicaly valid for a schema? or is wrong and the external company should change the base type to a bigger one?
Thanks in advance.
The restriction is fine. Have a look at the W3C standard.
[Definition:] positiveInteger is ·derived· from nonNegativeInteger by setting the value of ·minInclusive· to be 1. This results in the standard mathematical concept of the positive integer numbers. The ·value space· of positiveInteger is the infinite set {1,2,...}. The ·base type· of positiveInteger is nonNegativeInteger.
What they probably mean this value to be is an xs:unsignedInt or xs:unsignedLong, but technically its correct.
Related
I've recently upgraded my project from Xerces-J 2.7.0 to Xerces-J 2.12.1 and I'm seeing a change in schema validation behaviour. I'm not entirely clear if my test is wrong or Xerces is.
Given this schema:
<?xml version='1.0'?>
<xsd:schema xmlns:xsd='http://www.w3.org/2001/XMLSchema'>
<!-- Schema to test facets for the xsd:base64Binary datatype. -->
<xsd:element name="facetTest" type="FacetTestComplexType"/>
<xsd:complexType name="FacetTestComplexType">
<xsd:sequence>
<xsd:element name='enumeration' type='EnumerationType' minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
<!-- ***** Enumeration ***** -->
<xsd:simpleType name='EnumerationType'>
<xsd:restriction base='xsd:base64Binary'>
<xsd:enumeration value='Ab1+'/>
<xsd:enumeration value='7 d Ec'/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
And this instance document:
<facetTest>
<enumeration>7dEc</enumeration>
</facetTest>
With Xerces-J 2.7.0 that instance document would be valid, however when using Xerces-J 2.12.1 it now is flagged as invalid.
I reviewed the schema base64binary specification and it's left me unclear on whether this should be valid (my code is right and Xerces-J is wrong) or visa versa. This is the passage that has thrown me:
Note that this grammar requires the number of non-whitespace characters in the lexical form to be a multiple of four, and for equals signs to appear only at the end of the lexical form; strings which do not meet these constraints are not legal lexical forms of base64Binary because they cannot successfully be decoded by base64 decoders.
Note: The above definition of the lexical space is more restrictive than that given in [RFC 2045] as regards whitespace -- this is not an issue in practice. Any string compatible with the RFC can occur in an element or attribute validated by this type, because the ·whiteSpace· facet of this type is fixed to collapse, which means that all leading and trailing whitespace will be stripped, and all internal whitespace collapsed to single space characters, before the above grammar is enforced.
According to the definition of enumeration, it restricts the value-space, not the lexical-space. In that case it seems the value-space appears to cover the original binary content. If that's the case, then the whitespace should be meaningless.
Any clarification on whether my code or Xerces is incorrect would be greatly appreciated.
I think your code is correct, and Xerces has started to behave incorrectly.
Although the base64 values in your enums look strange, they do conform to the grammar specified here: https://www.w3.org/TR/xmlschema-2/#base64Binary
This is what the XSD spec says about enumeration facets:
Validation Rule: enumeration valid:
A value in a ·value space· is facet-valid with respect to ·enumeration· if the value is one of the values specified in {value}
So I agree with your statement:
According to the definition of enumeration, it restricts the value-space, not the lexical-space. In that case it seems the value-space appears to cover the original binary content.
I need to enforce the pattern LASTNAME/FIRSTNAME Something like Smith/John.
The characters can be Alphanumeric (lowercase/uppercase) also includes special characters like ë etc.
Pattern:
<xsd:pattern value="[a-zA-Z0-9]/[a-zA-Z0-9]"/>
Basically the rules will be
- Anything before the slash
- Anything after the slash
- Patterns like "/John", "John/" should not be allowed
Thanks in advance.
ASCII
Assuming that you don't want numbers in the names:
<xs:pattern value="[a-zA-Z]+/[a-zA-Z]+"/>
If you really want to accept numbers in the names:
<xs:pattern value="[a-zA-Z0-9]+/[a-zA-Z0-9]+"/>
Be aware that 0/0, for example, would be valid in this case, though.
Unicode
<xs:pattern value="\p{L}+/\p{L}+"/>
Explanation: \p{L} matches a Unicode code point in the Letter category.
Your restriction should be this..
<xs:pattern value="(([a-zA-Z0-9])*)([/])(([a-zA-Z0-9])*)"/>
I validated this pattern by XMLSpear
I'm creating web service by gSoap, using existing WSDL and the necessary schemas as argument for the command wsdl2h.
I have in my schema the element i_ID declared this way :
<xs:element minOccurs="0" name="i_ID" nillable="true" type="xs:string" />
But gSoap rename the attribute to i_USCOREID :
/// Element i_ID of type xs:string.
char* i_USCOREID
And I noticed it happens the same for all the fields after each _.
Do you know guys how to fix this? Because this reduces the readablity and I'm not right to change the .XSD file. Maybe I should add an option to the command wsdl2h?
Thank you!
use the "-_" flag when using the wsdl2h
"-_ don't generate _USCORE (replace with UNICODE _x005f)"
I encountered a parsing error with Apache CXF while processing a webservice response. What it comes down to is an empty element being returned:
<myValue />
The element definition is as follows:
<xsd:element name="myValue" type="xsd:float" minOccurs="0">
Now I've read on the CXF mailing list that an empty value is not allowed by the XSD-spec:
Well, there isn't a workaround for
this as it's not a bug. An empty
element is not valid for any Decimal
or Date type or anything like that.
Thus, it SHOULD throw an exception.
What are you expecting it to do?
Now here comes the question: Where exactly can I find this constraint in the XML Schema specification?
Where exactly can I find this constraint in the XML Schema specification?
http://www.w3.org/TR/xmlschema-2/#float-lexical-representation
float values have a lexical
representation consisting of a
mantissa followed, optionally, by the
character "E" or "e", followed by an
exponent.
...
The representations for exponent and
mantissa must follow the lexical rules
for integer and decimal.
...
The special values positive and
negative infinity and not-a-number
have lexical representations INF, -INF
and NaN, respectively.
So xs:float requires at least a mantissa that is a xs:decimal...
decimal has a lexical representation
consisting of a finite-length sequence
of decimal digits (#x30-#x39)
separated by a period as a decimal
indicator. An optional leading sign is
allowed.
...and an empty string is not a valid xs:decimal.
If you don't have a value for this element, you should try not including this element, if possible. Your schema seems to allow omitting this element because minOccurs has value 0. Other solution would be to insert a suitable replacement value, like 0 or NaN.
This is not a definitive constraint.
You should be able to change your xsd to
<xsd:element name="myValue" type="xsd:float" minOccurs="0" default="0" />
And then be able to supply an empty element for your float without causing your xml to be invalid.
The above example means that if the element is empty, then its value is 0. Beware, default attribute does not apply on missing elements: missing elements are just missing, whether they have a declared default or not.
http://www.w3.org/TR/xmlschema-0/#OccurrenceConstraints
if the element appears without any content, the schema processor provides the element with a value equal to that of the default attribute. However, if the element does not appear in the instance document, the schema processor does not provide the element at all.
I have not used this till now, but to guard against a personal miss-reading of w3c specs, I have check with an online validator that an xml with an empty xs:float element having a default was accepted (at least by this online validator: http://www.freeformatter.com/xml-validator-xsd.html ).
I have a tag like this
<order>foo,bar,goo,doo,woo</order>
that I need to validate with an xsd.
How do I write a regexp pattern that matches the string that contains:
List item any of {foo,bar,goo,doo,woo} maximum once
or is empty.
Valid examples:
<order>foo,bar,goo,doo,woo</order>
<order>foo,bar,goo</order>
<order>foo,doo,goo,woo</order>
<order>woo,foo,goo,doo,bar</order>
<order></order>
Invalid:
<order>foo,foo</order>
<order>,</order>
<order>fo</order>
<order>foobar</order>
This have to work in different XML/XSD parsers.
I don't think you can express all the rules in a regular expression. Especially, it will be tough to enforce "maximum once". This is the closest I come up with,
<xs:simpleType name="order">
<xs:annotation>
<xs:documentation>
Comma-separated list of anything
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="[^,]+(,\s*[^,]+)*"/>
</xs:restriction>
</xs:simpleType>
You might want try to use space as separator. That's more common in XML files. XML Schema has a builtin type "list" defined for space-separated list.
I can write a schema file if they follow some sequence .. like {foo,bar,goo,doo,woo}
but in your case, you say that, they can appear in ANY SEQUENCE.. so (5P5+5P4+5P3+5P2+5P1+1) = 326 patterns .. !!!
If there was some sequence as I mentioned .. then the number of patterns would have been .. 32 .. bearable..