jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • castor
  • CASTOR-279

Source Generator: Multiple pattern strings ignored

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 0.9.3.9
  • Fix Version/s: 1.1 M2
  • Component/s: XML code generator
  • Labels:
    None
  • Environment:
    Operating System: Windows 2000
    Platform: PC
  • Bugzilla Id:
    1136

Description

When a given element contains multiple pattern strings for validation, only the
first one is being picked up by the Source Generator for use. Such as:

<xs:restriction base="xs:string">
<xs:pattern
value="((([a-zA-Z]{6})|([a-zA-Z]{1}-[a-zA-Z]{4})|([a-zA-Z]{2}-[a-zA-Z]{3})|([a-z
A-Z]{3}-[a-zA-Z]{2})|([a-zA-Z]{4}-[a-zA-Z]{1})|([a-zA-Z]{5}-))\d{4})"/>
<xs:pattern
value="((([a-zA-Z]{5})|([a-zA-Z]{1}-[a-zA-Z]{3})|([a-zA-Z]{2}-[a-zA-Z]{2})|([a-z
A-Z]{3}-[a-zA-Z]{1})|([a-zA-Z]{4}-))\d{5})"/>
<xs:pattern
value="((([a-zA-Z]{4})|([a-zA-Z]{1}-[a-zA-Z]{2})|([a-zA-Z]{2}-[a-zA-Z]{1})|([a-z
A-Z]{3}-))\d{6})"/>
<xs:pattern
value="((([a-zA-Z]{3})|([a-zA-Z]{1}-[a-zA-Z]{1})|([a-zA-Z]{2}-))\d{7})"/>
</xs:restriction>

patterns 2-4 are not added to the code.

  • Options
    • Sort By Name
    • Sort By Date
    • Ascending
    • Descending
    • Download All

Attachments

  1. File
    castor-279.diff
    28/Dec/06 12:43 AM
    53 kB
    Edward Kuns

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Arnaud Blandin added a comment - 20/Dec/02 2:18 AM

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

Show
Arnaud Blandin added a comment - 20/Dec/02 2:18 AM Accepted...The pattern validator will need be enhanced to support multiple patterns
Hide
Permalink
Edward Kuns added a comment - 11/Oct/06 11:46 PM

Is this valid XML?

Show
Edward Kuns added a comment - 11/Oct/06 11:46 PM Is this valid XML?
Hide
Permalink
Werner Guttmann added a comment - 12/Oct/06 3:18 AM

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>

Show
Werner Guttmann added a comment - 12/Oct/06 3:18 AM 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>
Hide
Permalink
Edward Kuns added a comment - 12/Oct/06 8:41 AM

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

Show
Edward Kuns added a comment - 12/Oct/06 8:41 AM To me that says it's valid XML and that the patterns should be OR'd together.
Hide
Permalink
Werner Guttmann added a comment - 12/Oct/06 8:51 AM

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

Show
Werner Guttmann added a comment - 12/Oct/06 8:51 AM So was my first impression, to be honest ... . Glad that my reading abilities seem to be on par with yours ...
Hide
Permalink
Jim Carter added a comment - 12/Oct/06 9:12 AM

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.

Show
Jim Carter added a comment - 12/Oct/06 9:12 AM 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.
Hide
Permalink
Edward Kuns added a comment - 12/Oct/06 9:54 AM

I guess sometimes I like to state the obvious.

Show
Edward Kuns added a comment - 12/Oct/06 9:54 AM I guess sometimes I like to state the obvious.
Hide
Permalink
Edward Kuns added a comment - 28/Dec/06 12:32 AM

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.

Show
Edward Kuns added a comment - 28/Dec/06 12:32 AM 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.
Hide
Permalink
Edward Kuns added a comment - 28/Dec/06 12:43 AM

Attaching the correct patch this time.

Show
Edward Kuns added a comment - 28/Dec/06 12:43 AM Attaching the correct patch this time.
Hide
Permalink
Edward Kuns added a comment - 28/Dec/06 1:01 AM

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

Show
Edward Kuns added a comment - 28/Dec/06 1:01 AM With this delivery, I get 300/300 OK tests in the CTF under both Java 5 and Java 1.4.2.

People

  • Assignee:
    Edward Kuns
    Reporter:
    jcarter
Vote (0)
Watch (0)

Dates

  • Created:
    02/Dec/02 8:37 AM
    Updated:
    20/Apr/07 10:23 AM
    Resolved:
    28/Dec/06 1:01 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.