Yes, the validator is correct, but not consistent. Validating against
another element, for example:
<xs:complexType name="SC">
<xs:all>
<xs:element name="XPathLocator" type="xs:string"/>
<xs:element name="PortionMarked" type="xs:int"/>
<xs:element name="C">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="u"/>
<xs:enumeration value="c"/>
<xs:enumeration value="s"/>
<xs:enumeration value="sf"/>
<xs:enumeration value="ts"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="Justification" type="xs:string"/>
<xs:element name="CA" type="xs:string"/>
</xs:all>
With the following code
SC sc = SC.Factory.newInstance();
List<XmlValidationError> errors = new
ArrayList<XmlValidationError>();
XmlOptions validateOptions = new XmlOptions();
validateOptions.setErrorListener(errors);
sc.validate(validateOptions);
for (XmlValidationError error : errors) {
System.out.println(error.toString());
}
I get the following printout:
error: cvc-complex-type.2.4c: Expected elements
'[EMAIL PROTECTED]://www.foo.bar [EMAIL PROTECTED]://www.foo.bar
[EMAIL PROTECTED]://www.foo.bar [EMAIL PROTECTED]://www.foo.bar
[EMAIL PROTECTED]://www.foo.bar' before the end of the
content
In other words, the above has been my experience with XmlBeans up to
testing against the SeriesNumber schema element below. I'm not sure why
all my elements except for the series number element validate like the
one above does.
If the way XmlBeans reported errors was consistent, I wouldn't be
concerned. Because I cannot discern a pattern between when the code
behaves one way or the other doesn't mean there isn't one, but just that
I cannot see it.
jvc
-----Original Message-----
From: Radu Preotiuc-Pietro [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 6:42 PM
To: [email protected]
Subject: Re: Validation not returning correct error
Well, the validator is correct, essentially (there is an error in the
content at that point, which error would go away if you added the
respective element). What you want is that the validator continue "as
if" that element was there and report any other errors which could occur
in that case in the content. Or maybe you want that specifically for the
case where there are missing elements at the end of the content.
This is something reasonable to do, but I would consider it as a small
feature rather than a bug. There is no limit to how much can the error
messages be improved as the code gets smarter in figuring out what the
user intended.
Radu
On Fri, 2007-03-16 at 10:09 -0400, Joseph Campolongo wrote:
> I have the following complex type in a separate file, of which I have
> an element
>
>
>
> <xs:element name="SeriesNumber" type="tp:SeriesNumber"/>
>
>
>
> <xs:complexType name="SeriesNumber">
>
> <xs:sequence>
>
> <xs:element name="Code0">
>
> <xs:simpleType>
>
> <xs:restriction base="xs:string">
>
> <xs:minLength value="1"/>
>
> <xs:maxLength value="4"/>
>
> </xs:restriction>
>
> </xs:simpleType>
>
> </xs:element>
>
> <xs:element name="Code1">
>
> <xs:simpleType>
>
> <xs:restriction base="xs:string">
>
> <xs:minLength value="1"/>
>
> <xs:maxLength value="4"/>
>
> </xs:restriction>
>
> </xs:simpleType>
>
> </xs:element>
>
> <xs:element name="Code2">
>
> <xs:simpleType>
>
> <xs:restriction base="xs:string">
>
> <xs:minLength value="2"/>
>
> <xs:maxLength value="4"/>
>
> </xs:restriction>
>
> </xs:simpleType>
>
> </xs:element>
>
> <xs:element name="Code3">
>
> <xs:simpleType>
>
> <xs:restriction base="xs:string">
>
> <xs:minLength value="2"/>
>
> <xs:maxLength value="4"/>
>
> </xs:restriction>
>
> </xs:simpleType>
>
> </xs:element>
>
> <xs:element name="Code4" nillable="true">
>
> <xs:simpleType>
>
> <xs:restriction base="xs:string">
>
> <xs:enumeration value="A"/>
>
> <xs:enumeration value="B"/>
>
> <xs:enumeration value="C"/>
>
> </xs:restriction>
>
> </xs:simpleType>
>
> </xs:element>
>
> <xs:element name="Code5" nillable="true">
>
> <xs:simpleType>
>
> <xs:restriction base="xs:positiveInteger">
>
> <xs:maxExclusive value="100"/>
>
> </xs:restriction>
>
> </xs:simpleType>
>
> </xs:element>
>
> </xs:sequence>
>
> </xs:complexType>
>
>
>
> I run the following code:
>
>
>
> SeriesNumber sn = SeriesNumber.Factory.newInstance();
>
>
>
> List<XmlValidationError> errors = new
> ArrayList<XmlValidationError>();
>
> XmlOptions validateOptions = new XmlOptions();
>
> validateOptions.setErrorListener(errors);
>
>
>
> sn.validate(validateOptions);
>
>
>
> for (XmlValidationError error : errors) {
>
> System.out.println(error.toString());
>
> }
>
>
>
> expecting to get a single error saying that 6 elements are missing.
> Instead, I get the following error:
>
>
>
> error: cvc-complex-type.2.4c: Expected element
> '[EMAIL PROTECTED]://www.foo.bar/types' before the end of the content
>
>
>
> Now, if I add the following line to the code:
>
>
>
> sn.setCode0("Foo");
>
>
>
> I get the error:
>
>
>
> error: cvc-complex-type.2.4c: Expected element
> '[EMAIL PROTECTED]://www.socom.mil/psyop_types' before the end of the
> content
>
>
>
> In other words, the validator is only picking up the first missing
> element, and then failing to progress through to the next.
>
>
>
> This does not work as I expect, and doesn't work like all the other
> types I've validated against. Is this a bug, or is there an
> explanation for this behavior?
>
>
>
> jvc
>
>
>
> ps. Looking into the code, the problem is that the names in the
> sequence after the first are not added to the list of names that are
> expected by the Validator. In Validator.java, line 953, the following
> check fails for all elements after the first invalid one:
>
>
>
> 953: if (state.test(sProp.getName()))
>
>
>
> Looking deeper into the code, in SchemaTypeVisitorImpl.java, line 386,
> the following check fails:
>
>
>
> 386: if (_top._processedChildCount != 0 || _top._curCount <
> _top._curMin)
>
>
>
> Actually, the currCount is 0 and the curMin is 1, so it fails.
> Unfortunately, I don't know that this means.
>
>
_______________________________________________________________________
Notice: This email message, together with any attachments, may contain
information of BEA Systems, Inc., its subsidiaries and affiliated
entities, that may be confidential, proprietary, copyrighted and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
