[
https://issues.apache.org/jira/browse/XERCESJ-1559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294671#comment-13294671
]
Jorge L. Williams edited comment on XERCESJ-1559 at 6/13/12 9:43 PM:
---------------------------------------------------------------------
Hi Mukul,
First let me state that I believe that your implementation is working correctly
with regard to XSD 1.0, at least the last time I looked at it. Basically if
the xsi:type is defined then the element is validated against that type.
Schema 1.1 also supports this behavior in section 3.3.4.6 Schema-Validity
Assessment (Element) (http://www.w3.org/TR/xmlschema11-1/#sec-cvc-assess-elt)
The informal rule states that:
"if no ·governing element declaration· is available, a ·governing type
definition· can be used instead"
The behavior also applies to child elements where it says:
"If the ·governing element declaration· is not available, the element may still
be ·strictly assessed· if a ·governing type definition· can be identified (e.g.
via the xsi:type attribute)"
The formal definition of whether an element can be strictly assessed is more
explicit
[Definition:] An element information item E is said to be strictly assessed if
and only if all of the following are true:
1 One of the following is true:
1.1All of the following are true:
1.1.1A ·non-absent· element declaration is known for E, namely its
·governing· declaration.
1.1.2 E's local ·validity· with respect to that declaration has been
evaluated as per Element Locally Valid (Element) (§3.3.4.3).
1.1.3 If that evaluation involved the evaluation of Element Locally
Valid (Type) (§3.3.4.4), clause 1 thereof is satisfied.
1.2All of the following are true:
1.2.1 E does not have a ·governing element declaration·.
1.2.2 A ·non-absent· type definition is known for E, namely its
·governing type definition·
1.2.3The local ·validity· of E with respect to its ·governing type
definition· has been evaluated as per Element Locally Valid (Type) (§3.3.4.4).
...
Essentially 1.1 is true if the element is defined and 1.2 is true if the
element is *not* defined but there is a type definition that's associated with
the element via xsi:type.
-jOrGe W.
was (Author: jorgew):
Hi Mukul,
First let me state that I believe that your implementation is working correctly
with regard to XSD 1.0, at least the last time I looked at it. Basically if
the xsi:type is defined then the element is validated against that type.
Schema 1.1 also supports this behavior in section 3.3.4.6 Schema-Validity
Assessment (Element) (http://www.w3.org/TR/xmlschema11-1/#sec-cvc-assess-elt)
The informal rule states that:
"if no ·governing element declaration· is available, a ·governing type
definition· can be used instead"
The behavior also applies to child elements where it says:
"If the ·governing element declaration· is not available, the element may still
be ·strictly assessed· if a ·governing type definition· can be identified (e.g.
via the xsi:type attribute)"
The formal definition of whether an element can be strictly assessed is more
explicit
[Definition:] An element information item E is said to be strictly assessed if
and only if all of the following are true:
1 One of the following is true:
1.1All of the following are true:
1.1.1A ·non-absent· element declaration is known for E, namely its
·governing· declaration.
1.1.2 E's local ·validity· with respect to that declaration has been
evaluated as per Element Locally Valid (Element) (§3.3.4.3).
1.1.3 If that evaluation involved the evaluation of Element Locally
Valid (Type) (§3.3.4.4), clause 1 thereof is satisfied.
1.2All of the following are true:
1.2.1 E does not have a ·governing element declaration·.
1.2.2 A ·non-absent· type definition is known for E, namely its
·governing type definition·
1.2.3The local ·validity· of E with respect to its ·governing type
definition· has been evaluated as per Element Locally Valid (Type) (§3.3.4.4).
...
Essentially 1.1 is true if the element is defined and 1.2 is true if the
element is *not* defined but there is a type definition that's associated with
the element via xsi:type.
-jOrGe W.
> absence of XML root element declaration is ignored, to determine XSD validity
> when xsi:type is used on an root XML element instance
> -----------------------------------------------------------------------------------------------------------------------------------
>
> Key: XERCESJ-1559
> URL: https://issues.apache.org/jira/browse/XERCESJ-1559
> Project: Xerces2-J
> Issue Type: Bug
> Components: XML Schema 1.0 Datatypes, XML Schema 1.1 Datatypes
> Affects Versions: 2.11.0
> Reporter: Jorge L. Williams
> Assignee: Mukul Gandhi
>
> In the latest XSD 1.1 branch, it looks like simple type assertions are not
> being enforced when the type is specified via the xsi:type attribute. I'm
> attaching a schema and instance documents as a reference.
> If I do
> java -cp $CLASSPATH jaxp.SourceValidator -fx -xsd11 -a assertion.xsd -i
> even_bad.xml
> I get a correct error, but if I do
> java -cp $CLASSPATH jaxp.SourceValidator -fx -xsd11 -a assertion.xsd -i
> number_bad.xml
> I don't get an error at all.
> assertion.xsd:
> ---------------------
> <schema
> elementFormDefault="qualified"
> attributeFormDefault="unqualified"
> xmlns="http://www.w3.org/2001/XMLSchema";
> xmlns:xsd="http://www.w3.org/2001/XMLSchema";
> xmlns:tst="http://www.rackspace.com/test/assertion";
> targetNamespace="http://www.rackspace.com/test/assertion";>
> <element name="even" type="tst:Even"/>
> <!-- Simple Types -->
> <simpleType name="Even">
> <restriction base="xsd:int">
> <minInclusive value="0"/>
> <maxInclusive value="100"/>
> <assertion test="$value mod 2 = 0"/>
> </restriction>
> </simpleType>
> </schema>
> -------------
> even_bad.xml
> -----------
> <even xmlns="http://www.rackspace.com/test/assertion";>13</even>
> -----------
> number_bad.xml
> ------------
> <number xmlns:tst="http://www.rackspace.com/test/assertion";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:type="tst:Even"
> >13</number>
> ------------
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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]
