[jira] Commented: (XERCESC-1659) Order sensitivity in schemaLocation and noNamespaceSchemaLocation

["Boris Kolpackov (JIRA)" <xe...@xml.apache.org>]

    [ http://issues.apache.org/jira/browse/XERCESC-1659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461616 ] 

Boris Kolpackov commented on XERCESC-1659:
------------------------------------------

I've figured out the first part of this issue. Xerces-C++ uses the namespace URI as a key to determine whether a grammar for a schema file specified in the import declaration or in the schemaLocation attribute has already been read. For the code that handles this in case of the schemaLocation attribute see resolveSchemaGrammar() in IGXMLScanner.cpp, line 1665.

Here is what happens for the first test case. The noNamespaceSchemaLocation attribute comes first and specifies the derived-user-config.xsd schema file. That file imports test-user-config.xsd which is defined in the http://www.dave.com/Base namespace. Then comes the schemaLocation attribute's turn which specifies users-config.xsd for the http://www.dave.com/Base namespace. But the grammar for this namespace is already present so users-config.xsd is skipped even though it is different from test-user-config.xsd. I am not sure whether this is Xerces-C++ bug or a general XML Schema design bug. I tend to think it is the latter.

I do not have an explanation for the core dump in the second test case, though.


> Order sensitivity in schemaLocation and noNamespaceSchemaLocation
> -----------------------------------------------------------------
>
>                 Key: XERCESC-1659
>                 URL: http://issues.apache.org/jira/browse/XERCESC-1659
>             Project: Xerces-C++
>          Issue Type: Bug
>          Components: Validating Parser (Schema) (Xerces 1.5 or up only)
>    Affects Versions: 2.7.0
>         Environment: all
>            Reporter: Boris Kolpackov
>         Attachments: test-case-1.tar.gz, test-case-2.tar.gz
>
>
> I am attaching two test cases (each consists of 3 schemas plus an XML instance). If you try to run domprint on the first test case, you will get the following error:
> $ domprint -v=always -n -s -f test-users.xml 
> Error at file "test-users.xml", line 6, column 78
>    Message: Unknown element 'b:UserDatabase'
> If you change the order of the schemaLocation and noNamespaceSchemaLocation attributes in test-users.xml then the error disappears.
> The second test case is a slight modification of the first test case with the only difference being the schemas with targetNamespace are now do not have a namespace, and the schema that used to be without a namespace (derived-user-config.xsd) now is in a namespace. If you run domprint on this test case, you will get the following error:
> $ domprint -v=always -n -s -f test-users.xml 
> Error at file "test-users.xml", line 6, column 55
>    Message: Unknown element 'UserDatabase'
> This seems to prove that for Xerces-C++, for some reason, it is important that the schema that declares the root element is mentioned in the first *Location attribute (nor matter whether schemaLocation or noNamespaceSchemaLocation). Now comes the surprise: if we reverse the order of the two attributes in the second test case, domprint terminates with segmentation fault. Examination of the core points to the IGXMLScanner.cpp, line 2288:
>             elemDecl = fGrammar->getElemDecl(
>                 uriId, nameRawBuf, qnameRawBuf, currentScope
>             );

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

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