[
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: [email protected]
For additional commands, e-mail: [email protected]
