[jira] Assigned: (XMLBEANS-153) "validate on set" feature doesn't catch values that are invalid against xs:int patterns

["Jacob Danner (JIRA)" <xm...@xml.apache.org>]

     [ https://issues.apache.org/jira/browse/XMLBEANS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jacob Danner reassigned XMLBEANS-153:
-------------------------------------

    Assignee: Jacob Danner  (was: Rajiv Bala)

> "validate on set" feature doesn't catch values that are invalid against xs:int patterns
> ---------------------------------------------------------------------------------------
>
>                 Key: XMLBEANS-153
>                 URL: https://issues.apache.org/jira/browse/XMLBEANS-153
>             Project: XMLBeans
>          Issue Type: Bug
>          Components: Validator
>    Affects Versions: Version 2 Beta 1
>            Reporter: Steve Traut
>         Assigned To: Jacob Danner
>            Priority: Minor
>
> Using XmlOptions.setValidateOnSet will set up XMLBeans to throw an exception in some cases, but not others. 
> For example, an exception will be thrown when schema restricts xs:int to a max value of 100, but a value higher is set. It will NOT throw an exception when schema restricts xs:int to a pattern of three numerals in succession, but a longer value is set. Setting a longer value does render the XML invalid, as a call to XmlObject.validate shows. But "validate on set" doesn't catch this. 
> "validate on set" should set up XMLBeans to catch *anything* that would be invalid in a call to the validate method. Otherwise, it's too counterintuitive to be useful.
> Here's a snippet of the Java code that tries to incorrectly set the value of an id attribute (defined in schema below):
>     public boolean isValidOnTheFly()
>     {
>         private XmlOptions validationOptions = new XmlOptions();
>         validationOptions.setValidateOnSet();
>         
>         TodolistDocument todoList = TodolistDocument.Factory.newInstance(validationOptions);
>         Todolist list = todoList.addNewTodolist();
>         ItemType item = list.addNewItem();
>         item.setName("Procrastinate");
>         item.setDescription("A new item.");
>         item.setAction(ActionType.SOMEDAY_MAYBE_DEFER);
>         
>         // Should throw an exception because the value renders the XML invalid.
>         item.setId(8587);
>         
>         System.out.println(todoList.validate());
>         return true;
>     }
> Here's a snippet from the schema I'm using. Note the id attribute defined as idType:
>     <xs:complexType name="itemType">
>         <xs:sequence>
>             <xs:element name="name" type="xs:string"/>
>             <xs:element name="description" type="xs:string"/>
>             <xs:element name="due_by" type="xs:dateTime"/>
>             <xs:element name="action" type="actionType"/>
>         </xs:sequence>
>         <xs:attribute name="id" type="idType"/> 
>     </xs:complexType>
> When the idType is defined as follows, the code throws an exception:
>     <xs:simpleType name="idType">
>         <xs:restriction base="xs:int">
>             <xs:maxExclusive value="100"/>
>         </xs:restriction>
>     </xs:simpleType>
> When the idType is defined this way, the code throws no exception, although the value set by the code above still renders the XML I'm building invalid:
>     <xs:simpleType name="idType">
>         <xs:restriction base="xs:int">
>             <xs:pattern value="[0-9][0-9][0-9]"/>
>         </xs:restriction>
>     </xs:simpleType>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org