castor
  1. castor
  2. CASTOR-1720

Add support for validating <xsd:ID> types elements/attributes

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.5
    • Fix Version/s: 1.1 M1
    • Component/s: XML code generator
    • Labels:
      None
    • Number of attachments :
      2

      Description

      Currently, the Castor XML code generator does not create any special validation logic for <xsd:ID> typed elements/attributes. As a result, it is currently impossible to assess that ...

      a) a content element typed with <xsd:ID> is not empty.
      b) there's more than one such content element with an identical value.

      The idea is to create a new IdValidator and modify the XML code generator to make sure that this new validator is called accordingly.

      1. patch.c1720.20061206.diff
        11 kB
        Werner Guttmann
      2. patch.c1720.20061206.tests.txt
        16 kB
        Werner Guttmann

        Issue Links

          Activity

          Hide
          Werner Guttmann added a comment -

          Initial patch for review.

          Show
          Werner Guttmann added a comment - Initial patch for review.
          Hide
          Werner Guttmann added a comment -

          The idea now is to add test case after test case to check various scenarios, and to validate the taken approach.

          Show
          Werner Guttmann added a comment - The idea now is to add test case after test case to check various scenarios, and to validate the taken approach.
          Hide
          Edward Kuns added a comment -

          Looks OK to me. Although on the new class you added, don't you want to put yourself as the author and change the copyright notice?

          Show
          Edward Kuns added a comment - Looks OK to me. Although on the new class you added, don't you want to put yourself as the author and change the copyright notice?
          Hide
          Werner Guttmann added a comment -

          Most definitely. I guess I will even move the new classes (and those largely refactored to the org.castor package). Thanks for reminding me .... .

          Show
          Werner Guttmann added a comment - Most definitely. I guess I will even move the new classes (and those largely refactored to the org.castor package). Thanks for reminding me .... .
          Hide
          Werner Guttmann added a comment -

          As a reminder to myself, so far validation during unmarshalling has been looked at. And adding - possibly maybe - life-cycle methods might become an issue as well.

          Show
          Werner Guttmann added a comment - As a reminder to myself, so far validation during unmarshalling has been looked at. And adding - possibly maybe - life-cycle methods might become an issue as well.
          Hide
          Werner Guttmann added a comment -

          JUnit tests relative to src/bugs.

          Show
          Werner Guttmann added a comment - JUnit tests relative to src/bugs.
          Hide
          Werner Guttmann added a comment -

          A little change: through this issue, only validation during marshalling should be addressed. Castor's Unmarshaller has already support for an IDResolver, which just needs to be expanded to deal with empty and duplicate IDs. This will be addressed through a separate Jira issue.

          Show
          Werner Guttmann added a comment - A little change: through this issue, only validation during marshalling should be addressed. Castor's Unmarshaller has already support for an IDResolver, which just needs to be expanded to deal with empty and duplicate IDs. This will be addressed through a separate Jira issue.

            People

            • Assignee:
              Werner Guttmann
              Reporter:
              Werner Guttmann
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 5 days, 1 hour, 30 minutes
                5d 1h 30m
                Remaining:
                Remaining Estimate - 5 days, 1 hour, 30 minutes
                5d 1h 30m
                Logged:
                Time Spent - Not Specified
                Not Specified