Source Generator: Multiple pattern strings ignored

Accepted...The pattern validator will need be enhanced to support multiple
patterns

Is this valid XML?

I am just reading http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#element-pattern, and somehow the information presented there does not really make it clearer. How about that selected statement:

<quote>
If multiple <pattern> element information items appear as [children] of a <simpleType>, the [value]s should be combined as if they appeared in a single - regular expression- as separate - branches.
</quote>

To me that says it's valid XML and that the patterns should be OR'd together.

So was my first impression, to be honest ... . Glad that my reading abilities seem to be on par with yours ...

Just to chime in here (a few years later...)

We did try concatenating all the conditions together into a single <xs:pattern> but the regExp parser in use at the time didn't like nested conditions > 10 and this particular one resulted in a whole lot more levels so we wound up writing other (non Castor) code to accomplish this validation.

I only add this as another thing to check when figuring out how to fix this. As I recall, the regExp parser used with Castor was "pluggable" and other parsers were able to handle it (I'm thinking maybe an Apache one?). Anyway, FYI...

Thanks,
Jim C.

I guess sometimes I like to state the obvious.

This was a little tougher than I anticipated, but I have it working. The code would attach every facet of a type, including facets it received from its base type, and then needed to filter out extra facets from the base type. Since Castor already independenty calls the validator for the base class (which is correct and suggested behavior according to references I have), we do not need to do this. I simplified so all facets attached directly to a given simple type are used, but facets attached to parents of the SimpleType are not used except when generating code for that parent.

If we're already going to valdiate against each class in the restriction/extension hierarchy, why try to do this extra validation independently at each level? Just validate each level against the facets it is specifically given and let the hierarchy take care of making sure that facets in a derived or extended class are not ouf of the range of facets in the base class.

I'm about to attach a patch.

Attaching the correct patch this time.

With this delivery, I get 300/300 OK tests in the CTF under both Java 5 and Java 1.4.2.