[jira] Updated: (XERCESJ-1408) assertions facet validation rules, improvements

["Mukul Gandhi (JIRA)" <xe...@xml.apache.org>]

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

Mukul Gandhi updated XERCESJ-1408:
----------------------------------

    Description: 
I think, implementation of following section of XSD 1.1 data types, xs:assertion facet spec need to be implemented in entirety, in Xerces-J: 
http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules 

Presently, the Xerces-J SVN code implements some parts of this spec. 

I find that following sections of the spec (quoted from the spec, itself), are not implemented correctly in Xerces-J: 

1. The in-scope variables in the static context is a set with a single member. The expanded QName of that member has no namespace URI and has 'value' as the local name. The (static) type of the member is anyAtomicType*. 
(the present Xerces SVN implementation, doesn't strictly implements this. The current implementation, assigns specific "built in" XSD types to the xpath2 "dynamic context" variable $variable, like xs:string, xs:date, etc depending on the XSD type, that exists in the XSD 1.1 schema on the simple type definition (which has assertion facets). We need to improve this, as per the spec.) 

2. There is no context item for the evaluation of the XPath expression. As a consequence the expression '.', or any implicit or explicit reference to the context item, will raise a dynamic error, which will cause the assertion to be treated as false. If an error is detected statically, then the assertion violates the schema component constraint XPath Valid and causes an error to be flagged in the schema. 
(the present implementation does cause a "xpath context" to exist, while evaluating the xs:assertion facet XPath expressions. the current implementation doesn't flag an error to the user, if an attempt is made to refer the expression '.' in assertion facet xpath expression. at least, the assertion should evaluate to false, in this case, even if we don't flag an explicit error for this.) 

To solve these issues, we also need to investigate the psychopath processor capabilities in this regard. 

I think, for the XSD 1.1 preview implementation, we have good enough spec conformance, to showcase the assertion facet implementation. But we can try to improve implementation of these parts of the spec, at the earliest.

  was:
Implementation of following section of XSD 1.1 data types, xs:assertion facet spec need to be implemented in entirety, in Xerces-J:
http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules

Presently, the Xerces SVN code implements some parts of this spec.

I find that following sections of the spec (quoted from the spec, itself), are not implemented correctly in Xerces-J:

1. The in-scope variables in the static context is a set with a single member. The expanded QName of that member has no namespace URI and has 'value' as the local name. The (static) type of the member is anyAtomicType*.
(the present implement doesn't strictly implement this. The current implementation, assigns specific "built in" XSD types to the xpath2 "dynamic context" variable $variable, like xs:string, xs:date, etc depending the XSD type, that exists in the schema on the simple type definition. We need to improve this, as per the spec.)

2. There is no context item for the evaluation of the XPath expression. As a consequence the expression '.', or any implicit or explicit reference to the context item, will raise a dynamic error, which will cause the assertion to be treated as false. If an error is detected statically, then the assertion violates the schema component constraint XPath Valid and causes an error to be flagged in the schema.
(the present implementation does cause a "xpath context" to exist, while evaluation the xs:assertion facet XPath expressions. the current implementation doesn't flag an error to the user, if an attempt is made to refer the expression '.' in assertion facet xpath expression. at least, the assertion should evaluate to false, in this case, even if we don't flag an explicit error for this.)

To solve these issues, we also need to investigate the psychopath processor capabilities in this regard.

I think, for the XSD 1.1 preview release, we have good enough implementation, to showcase the assertion facet implementation. But we can try to improve implementation of these parts of the spec, at the earliest.


doing some minor improvements to the text, of the issue.

> assertions facet validation rules, improvements
> -----------------------------------------------
>
>                 Key: XERCESJ-1408
>                 URL: https://issues.apache.org/jira/browse/XERCESJ-1408
>             Project: Xerces2-J
>          Issue Type: Improvement
>          Components: XML Schema 1.1 Datatypes
>    Affects Versions: 2.10.0
>            Reporter: Mukul Gandhi
>
> I think, implementation of following section of XSD 1.1 data types, xs:assertion facet spec need to be implemented in entirety, in Xerces-J: 
> http://www.w3.org/TR/2009/CR-xmlschema11-2-20090430/#assertions-validation-rules 
> Presently, the Xerces-J SVN code implements some parts of this spec. 
> I find that following sections of the spec (quoted from the spec, itself), are not implemented correctly in Xerces-J: 
> 1. The in-scope variables in the static context is a set with a single member. The expanded QName of that member has no namespace URI and has 'value' as the local name. The (static) type of the member is anyAtomicType*. 
> (the present Xerces SVN implementation, doesn't strictly implements this. The current implementation, assigns specific "built in" XSD types to the xpath2 "dynamic context" variable $variable, like xs:string, xs:date, etc depending on the XSD type, that exists in the XSD 1.1 schema on the simple type definition (which has assertion facets). We need to improve this, as per the spec.) 
> 2. There is no context item for the evaluation of the XPath expression. As a consequence the expression '.', or any implicit or explicit reference to the context item, will raise a dynamic error, which will cause the assertion to be treated as false. If an error is detected statically, then the assertion violates the schema component constraint XPath Valid and causes an error to be flagged in the schema. 
> (the present implementation does cause a "xpath context" to exist, while evaluating the xs:assertion facet XPath expressions. the current implementation doesn't flag an error to the user, if an attempt is made to refer the expression '.' in assertion facet xpath expression. at least, the assertion should evaluate to false, in this case, even if we don't flag an explicit error for this.) 
> To solve these issues, we also need to investigate the psychopath processor capabilities in this regard. 
> I think, for the XSD 1.1 preview implementation, we have good enough spec conformance, to showcase the assertion facet implementation. But we can try to improve implementation of these parts of the spec, at the earliest.

-- 
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: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org