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

Mukul Gandhi updated XERCESJ-1496:
----------------------------------

    Description: 
Here's a description of the rationale and benefits of this change, and a small 
schema 1.1 validation use case illustrating the proposed changes.

One of the test cases in W3C XML Schema 1.1 test suite is as follows:

XML document [1]:
<list>1 2 3 4 5</list>

XML Schema 1.1 document [2]:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
   
    <xs:element name="list">
         <xs:simpleType>
             <xs:list>
                 <xs:simpleType>
                     <xs:restriction base="xs:integer">
                         <xs:assertion test="count($value) eq 
count(distinct-values($value))" />
                     </xs:restriction>
                 </xs:simpleType>
             </xs:list>
         </xs:simpleType>
    </xs:element>
   
</xs:schema>

The assertion facet in this example would mean,
"there must be no duplicates in the list"

Xerces (before this change) didn't support an use case like above. For the 
above example currently Xerces evaluates assertion for each list item 
(therefore Xerces would make 5 calls to an assertion for this example, and the 
XPath 2 context variable $value being different/"list item" in each iteration) 
-- but this would not serve the purpose of this use case.

I believe we must support this use case. To support this facility I propose a 
change along the following lines:
We introduce a new feature on JAXP validator with name 
"http://apache.org/xml/features/validation/foldedSTlist-assertion-evaluation"; 
whose default value is an boolean 'false' (therefore not setting this feature 
or making it explicitly 'false' would retain the current Xerces behavior). 
Setting this feature to 'true' would cause assertion evaluation as required by 
the above use case.

The current Xerces implementation to evaluate assertion facet on each list item 
is also beneficial; for example with a schema 1.1 fragment something like below:
<xs:element name="list">
     <xs:simpleType>
        <xs:list>
           <xs:simpleType>
               <xs:restriction base="xs:integer">
                   <xs:assertion test="$value mod 2 = 0" />
               </xs:restriction>
           </xs:simpleType>
        </xs:list>
    </xs:simpleType>
</xs:element>

(the assertion failure error messages in this example would tell us, that what 
all list items didn't pass the test AND I believe that this run-time behavior 
is also useful)

To summarize this change:
1. Setting the mentioned JAXP feature to 'true' would cause assertion to be 
evaluated only once on the entire list (which would have a type annotation 
xs:anyAtomicType*).
2. Not setting this JAXP feature explicitly (since it's default value is 
'false' within Xerces XML Schema 1.1 validator), or setting explicitly it's 
value to 'false' would retain the current Xerces behavior as has been explained 
above.

I hope that this enhancement is useful. I'll shortly be committing changes for 
this facility (along with related support to jaxp.SourceValidator sample). Any 
comments about this change would be helpful to us.

  was:
Here' a description of the rationale and benefits of this change, and a small 
schema 1.1 validation use case illustrating the proposed changes.

One of the test cases in W3C XML Schema 1.1 test suite is as follows:

XML document [1]:
<list>1 2 3 4 5</list>

XML Schema document [2]:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
   
    <xs:element name="list">
         <xs:simpleType>
             <xs:list>
                 <xs:simpleType>
                     <xs:restriction base="xs:integer">
                         <xs:assertion test="count($value) eq 
count(distinct-values($value))" />
                     </xs:restriction>
                 </xs:simpleType>
             </xs:list>
         </xs:simpleType>
    </xs:element>
   
</xs:schema>

The assertion facet in this example would mean,
"there must be no duplicates in the list"

Xerces (before this change) didn't support an use case like above. For the 
above example Xerces evaluates assertion for each list item (therefore Xerces 
would make 5 calls to an assertion for this example, and the XPath 2 context 
variable $value being different/"list item" in each iteration) -- but this 
would not serve the purpose of this use case.

I believe we must support this use case. To support this facility I propose a 
change along the following lines:
Introduce a new feature on JAXP validator with name 
"http://apache.org/xml/features/validation/foldedSTlist-assertion-evaluation"; 
whose default value is an boolean 'false' (therefore not setting this feature 
or making it explicitly 'false' would retain the current Xerces behavior). 
Setting this feature to 'true' would cause assertion evaluation as required by 
the above use case.

The current Xerces implementation to evaluate assertion facet on each list item 
is also beneficial; for example with a schema 1.1 fragment something like below:
<xs:element name="list">
     <xs:simpleType>
        <xs:list>
           <xs:simpleType>
               <xs:restriction base="xs:integer">
                   <xs:assertion test="$value mod 2 = 0" />
               </xs:restriction>
           </xs:simpleType>
        </xs:list>
    </xs:simpleType>
</xs:element>

(the assertion failure error messages in this example would tell us, that what 
all list items didn't pass the test AND I believe that this run-time behavior 
is also useful)

To summarize this change:
1. Setting the mentioned JAXP feature to 'true' would cause assertion to be 
evaluated only once on the entire list (which would have a type annotation 
xs:anyAtomicType*).
2. Not setting this JAXP feature explicitly (since it's default value is 
'false' within Xerces XML Schema 1.1 validator), or setting explicitly it's 
value to 'false' would retain the current Xerces behavior as has been explained 
above.

I hope that this enhancement is useful. I'll shortly be committing changes for 
this facility (along with related support in jaxp.SourceValidator sample). Any 
comments about this change would be helpful to us.


> adding new feature to JAXP validator for folded simpleType->list assertions 
> evaluation
> --------------------------------------------------------------------------------------
>
>                 Key: XERCESJ-1496
>                 URL: https://issues.apache.org/jira/browse/XERCESJ-1496
>             Project: Xerces2-J
>          Issue Type: Improvement
>          Components: XML Schema 1.1 Structures
>    Affects Versions: 2.11.0
>            Reporter: Mukul Gandhi
>            Assignee: Mukul Gandhi
>            Priority: Minor
>
> Here's a description of the rationale and benefits of this change, and a 
> small schema 1.1 validation use case illustrating the proposed changes.
> One of the test cases in W3C XML Schema 1.1 test suite is as follows:
> XML document [1]:
> <list>1 2 3 4 5</list>
> XML Schema 1.1 document [2]:
> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
>    
>     <xs:element name="list">
>          <xs:simpleType>
>            <xs:list>
>                <xs:simpleType>
>                    <xs:restriction base="xs:integer">
>                        <xs:assertion test="count($value) eq 
> count(distinct-values($value))" />
>                    </xs:restriction>
>                </xs:simpleType>
>            </xs:list>
>          </xs:simpleType>
>     </xs:element>
>    
> </xs:schema>
> The assertion facet in this example would mean,
> "there must be no duplicates in the list"
> Xerces (before this change) didn't support an use case like above. For the 
> above example currently Xerces evaluates assertion for each list item 
> (therefore Xerces would make 5 calls to an assertion for this example, and 
> the XPath 2 context variable $value being different/"list item" in each 
> iteration) -- but this would not serve the purpose of this use case.
> I believe we must support this use case. To support this facility I propose a 
> change along the following lines:
> We introduce a new feature on JAXP validator with name 
> "http://apache.org/xml/features/validation/foldedSTlist-assertion-evaluation"; 
> whose default value is an boolean 'false' (therefore not setting this feature 
> or making it explicitly 'false' would retain the current Xerces behavior). 
> Setting this feature to 'true' would cause assertion evaluation as required 
> by the above use case.
> The current Xerces implementation to evaluate assertion facet on each list 
> item is also beneficial; for example with a schema 1.1 fragment something 
> like below:
> <xs:element name="list">
>      <xs:simpleType>
>         <xs:list>
>          <xs:simpleType>
>              <xs:restriction base="xs:integer">
>                  <xs:assertion test="$value mod 2 = 0" />
>              </xs:restriction>
>          </xs:simpleType>
>         </xs:list>
>     </xs:simpleType>
> </xs:element>
> (the assertion failure error messages in this example would tell us, that 
> what all list items didn't pass the test AND I believe that this run-time 
> behavior is also useful)
> To summarize this change:
> 1. Setting the mentioned JAXP feature to 'true' would cause assertion to be 
> evaluated only once on the entire list (which would have a type annotation 
> xs:anyAtomicType*).
> 2. Not setting this JAXP feature explicitly (since it's default value is 
> 'false' within Xerces XML Schema 1.1 validator), or setting explicitly it's 
> value to 'false' would retain the current Xerces behavior as has been 
> explained above.
> I hope that this enhancement is useful. I'll shortly be committing changes 
> for this facility (along with related support to jaxp.SourceValidator 
> sample). Any comments about this change would be helpful to us.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to