In other words, validation for a <sequence> differs from validation for an <all>. In both cases, validation fails as soon as the code can determine there is an error.
In the <sequence> case, this is when the first element is missing. In the <all> case, this is at the end-tag of the element in question. Thank you, jvc -----Original Message----- From: Radu Preotiuc-Pietro [mailto:[EMAIL PROTECTED] Sent: Monday, March 19, 2007 4:23 PM To: [email protected] Subject: RE: Validation not returning correct error Well, the pattern is the following: In your first example (even though the error messages are not consistent with the Schema you posted), the "compositor" is <sequence> which means of course an ordered sequence of elements: the validator is expecting a <Code0> element, followed by <Code1>, <Code2>, <Code3>, <Code4> and then <Code5> elements. But it expects <Code0> _first_. When it reaches the end of the enclosing element without seeing a <Code0> it reports that saying "Hey, the element has already ended but I was looking for <Code0>. What it doesn't do is look at it and say "Well, even if <Code0> was present, after that I would needea <Code1>, then <Code2> etc. In your second example, since the compositor is "all", the elements can appear in whatever order, as long as they all appear. So when the validator encounters the end of content without seeing those elements, it reports that it was expecting _any_ of the given elements, not just one in particular. So this is the thing that is consistent: the validator reports a set of element names, any of which, if added "before the end" of the enclosing element would bring the content one step closer to being valid. Hope this helps, it's kind of difficult to explain in e-mail. Radu On Mon, 2007-03-19 at 08:34 -0400, Joseph Campolongo wrote: > 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] > _______________________________________________________________________ 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]
