DO NOT REPLY [Bug 7315] New: - unique Identity constraint fails

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7315>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7315

unique Identity constraint fails

           Summary: unique Identity constraint fails
           Product: Xerces2-J
           Version: 2.0.1
          Platform: PC
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: Other
         Component: XML Schema Structures
        AssignedTo: xerces-j-dev@xml.apache.org
        ReportedBy: stan.brown@unisys.com


The parser does not always enforce this identity constraint.

from the following schema extract:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns="file:///D:/drummer/jcaImpl"
    targetNamespace="file:///D:/drummer/jcaImpl"
    elementFormDefault="qualified">

  <xsd:element name="COMSRecord" type="COMSRecordType">
    <xsd:unique name="COMSRecordKey">
      <xsd:selector xpath="COMSRecord"/>
      <xsd:field xpath="@name"/>
    </xsd:unique>
  </xsd:element>

  <xsd:complexType name="COMSRecordType">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
<!--
      <xsd:element name="COMSDate" type="COMSDataType"/>
      <xsd:element name="COMSField" type="COMSFieldType"/>
      <xsd:element name="COMSArray" type="COMSArrayType"/>
-->
      <xsd:element name="COMSRecord" type="COMSRecordType">

      </xsd:element>
    </xsd:choice>
    <xsd:attribute name="name" type="xsd:string" use="required"/>
  </xsd:complexType>
...
</xsd:schema>

And the following xml file:

<?xml version='1.0' encoding='UTF-8'?>
<COMSRecord xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="file:///D:/drummer/jcaImpl"
    xsi:schemaLocation="file:///D:/drummer/jcaImpl 
file:///d:/drummer/jcaImpl/jrac.xsd"
    name="testRecord4">

  <COMSRecord name="testRecord4">

    <COMSRecord name="testRecord6"></COMSRecord>

    <COMSRecord name="testRecord6"></COMSRecord>

 </COMSRecord>
  <COMSRecord name="testRecord4"></COMSRecord>
  <!--  <COMSDate name="testRecord3">binary</COMSDate> -->
</COMSRecord>
 
The parser fails to invalidate the xml file.

If I change the "selector" statement to "*", the parser will invalidate the xml 
file, but this is not the intended behavaior since it takes every element into 
account.

One other thing, if I move the (or add a second) unique identity constraint 
under the COMSRrecord element located inside the COMSRecordType complexType, 
the parser throws a NullPointerException, here's the stack trace:

f = D:\drummer\jcaImpl\COMSRecord.xml
java.lang.NullPointerException
        at org.apache.xerces.impl.xs.XMLSchemaValidator$ValueStoreBase.append
(XMLSchemaValidator.java:3218)
        at 
org.apache.xerces.impl.xs.XMLSchemaValidator$ValueStoreCache.transplant
(XMLSchemaValidator.java:3761)
        at org.apache.xerces.impl.xs.XMLSchemaValidator.handleEndElement
(XMLSchemaValidator.java:1976)
        at org.apache.xerces.impl.xs.XMLSchemaValidator.endElement
(XMLSchemaValidator.java:694)
        at org.apache.xerces.impl.XMLNamespaceBinder.handleEndElement
(XMLNamespaceBinder.java:853)
        at org.apache.xerces.impl.XMLNamespaceBinder.endElement
(XMLNamespaceBinder.java:643)
        at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement
(XMLDTDValidator.java:2978)
        at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement
(XMLDTDValidator.java:918)
        at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.handleEndElement
(XMLDocumentFragmentScannerImpl.java:1145)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanEndElement
(XMLDocumentFragmentScannerImpl.java:988)
        at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.
dispatch(XMLDocumentFragmentScannerImpl.java:1446)
        at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument
(XMLDocumentFragmentScannerImpl.java:333)
        at org.apache.xerces.parsers.StandardParserConfiguration.parse
(StandardParserConfiguration.java:529)
        at org.apache.xerces.parsers.StandardParserConfiguration.parse
(StandardParserConfiguration.java:585)
        at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147)
        at org.apache.xerces.parsers.DOMParser.parse(DOMParser.java:160)
        at RAConfig.readXml2(RAConfig.java:508)
        at RAConfig.<init>(RAConfig.java:325)
        at RAConfig.main(RAConfig.java:778)

Also, using different values for the "selector" causes the NullPointerException 
to be thrown from different locations.  Another location was at line 1314 in 
XMLSchemaValidator. Looking for another source to validated my findings, I 
downloaded XMLSpy and successfully validated the schema and generated an XML 
file from it - not that this proves there is a real problem, but it is 
something to compare against.  Tracing through the source, I noticed a comment 
that this area may be revisited.  Also, I can understand if the recursion is 
unacceptable by the w3c standard (or perhaps its just wrong), but I would not 
expected to recevie a NullPointerException.

---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-j-dev-help@xml.apache.org