You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by bu...@apache.org on 2001/06/12 14:37:52 UTC
[Bug 2129] New: - Namespace and type mixup in validation
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2129
*** shadow/2129 Tue Jun 12 05:37:52 2001
--- shadow/2129.tmp.4459 Tue Jun 12 05:37:52 2001
***************
*** 0 ****
--- 1,117 ----
+ +============================================================================+
+ | Namespace and type mixup in validation |
+ +----------------------------------------------------------------------------+
+ | Bug #: 2129 Product: Xerces-J |
+ | Status: NEW Version: CVS extract |
+ | Resolution: Platform: All |
+ | Severity: Major OS/Version: All |
+ | Priority: Other Component: Schema-Structures |
+ +----------------------------------------------------------------------------+
+ | Assigned To: xerces-j-dev@xml.apache.org |
+ | Reported By: udo.grabowski@imk.fzk.de |
+ | CC list: Cc: |
+ +----------------------------------------------------------------------------+
+ | URL: |
+ +============================================================================+
+ | DESCRIPTION |
+ This is a real weird one:
+
+ (xerces 1.4.0 and CVS from 11-Jun-01, validation with sample program
+ dom.DOMWriter, flags -v -f, seen on Linux 2.4.x/Java 1.3/gcc 2.95.2
+ and Solaris 8/Java 1.2.1)
+
+ The following document references two named types from a schema which is
+ composed of two subschemata imported into the coupling schema. The validator
+ mixes up the types of the two namespaces, so a wrong validation result is
+ delivered. I'm not completely shure if my schemas are entirely correct
+ (but who is ...), but in either case the behaviour of the parser is wrong
+ (at least some clarifying error message would be expected instead of
+ wrong results).
+ I found in the schema:structures W3C recommendation that
+ a parser may ignore a second import, but close inspection
+ of the (really hard to read) constraints shows that this only applies to
+ a second import of the same namespace, not a different one.
+
+ Here are the results for the attached collection of schemas:
+ ame wisa expected seen
+ ------------------------------------------------------------------------
+ D D ame invalid, wisa valid ame invalid, wisa invalid
+ D T ame invalid, wisa invalid ame invalid, wisa valid
+ T T ame valid , wisa invalid ame valid , wisa valid
+ T D ame valid , wisa valid ame valid , wisa invalid
+ ------------------------------------------------------------------------
+ In all cases wisa:val is validated with the ame:valid restriction pattern.
+ If I exchange the order of the import statements, it's just the other way
+ round. But if I declare the wisa:val type as a, say, fixed string, that
+ string correctly appears in the output (as all entries are correctly echoed
+ to the output in this example). The severe thing here is that the types are
+ mixed up although they have not only different namespaces, but also different
+ names !
+ The problem is stable when variying references (prefixing element or type
+ references, varying default namespace).
+
+ ============== The document: ============================================
+ <?xml version="1.0"?>
+ <imk2:root xmlns:imk2="http://www-imk.fzk.de/imk2/"
+ xmlns:ame="http://www-imk.fzk.de/imk2/ame/"
+ xmlns:wisa="http://www-imk.fzk.de/imk2/wisa/"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xsi:schemaLocation="http://www-imk.fzk.de/imk2/ oh.xsd">
+
+ <!-- ame"D" is invalid content, wisa"D" is valid -->
+
+ <ame:valid>D</ame:valid>
+ <wisa:val>D</wisa:val>
+
+ </imk2:root>
+ ================= The coupling schema oh.xsd =======================
+
+ <?xml version="1.0"?>
+ <schema targetNamespace="http://www-imk.fzk.de/imk2/"
+ xmlns:imk2="http://www-imk.fzk.de/imk2/"
+ xmlns:wisa="http://www-imk.fzk.de/imk2/wisa/"
+ xmlns:ame="http://www-imk.fzk.de/imk2/ame/">
+
+ <import namespace="http://www-imk.fzk.de/imk2/ame/"
+ schemaLocation="file:ame.xsd"/>
+ <import namespace="http://www-imk.fzk.de/imk2/wisa/
+ schemaLocation="file:wisa.xsd"/>
+
+ <element name="root" type="imk2:rootType"/>
+
+ <complexType name="rootType">
+ <sequence>
+ <element ref="ame:valid"/>
+ <element ref="wisa:val"/>
+ </sequence>
+ </complexType>
+ </schema>
+ ===================== Base schema ame.xsd ===========================
+ <?xml version="1.0"?>
+ <schema targetNamespace="http://www-imk.fzk.de/imk2/ame/"
+ xmlns:ame="http://www-imk.fzk.de/imk2/ame/">
+
+ <element name="valid">
+ <simpleType>
+ <restriction base="string">
+ <pattern value="(T|F)"/>
+ </restriction>
+ </simpleType>
+ </element>
+
+ </schema>
+ ======================= Base schema wisa.xsd =======================
+ <?xml version="1.0"?>
+ <schema targetNamespace="http://www-imk.fzk.de/imk2/wisa/"
+ xmlns:wisa="http://www-imk.fzk.de/imk2/wisa/">
+
+ <element name="val">
+ <simpleType>
+ <restriction base="string">
+ <pattern value="(D|K)"/>
+ </restriction>
+ </simpleType>
+ </element>
+
+ </schema>
+ ===================== end of example ====================================
\ No newline at end of file
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org