[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    [jira] Assigned: (XMLBEANS-153) "validate on set" feature doesn't
From:       "Jacob Danner (JIRA)" <xmlbeans-dev () xml ! apache ! org>
Date:       2007-04-25 15:26:16
Message-ID: 27303347.1177514776184.JavaMail.jira () brutus
[Download RAW message or body]


     [ 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


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic