[jira] Updated: (XERCESJ-959) Location properties incorrect on XSDDescription when using Entity Resolver

[ji...@apache.org]

The following issue has been updated:

    Updater: Lucian Holland (mailto:lefh@decisionsoft.com)
       Date: Tue, 11 May 2004 1:47 AM
    Comment:
Java test class to reproduce bug
    Changes:
             Attachment changed to Test.java
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://issues.apache.org/jira/browse/XERCESJ-959?page=history

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/XERCESJ-959

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: XERCESJ-959
    Summary: Location properties incorrect on XSDDescription when using Entity Resolver
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Xerces2-J
 Components: 
             XNI
   Versions:
             2.6.2

   Assignee: 
   Reporter: Lucian Holland

    Created: Tue, 11 May 2004 1:43 AM
    Updated: Tue, 11 May 2004 1:47 AM

Description:
When a SchemaGrammar is loaded from a location specified by the parser's Entity Resolver rather than from the location specified by a location hint contained in the referencing document, the "expandedSystemId" and "literalSystemId" properties of that SchemaGrammar's XMLGrammarDescription are incorrect. (See attached test)

This is because XSDHandler creates the XMLGrammarDescription by cloning the one that was created to request the grammar; but if the XMLInputSource used to load the grammar was created by a user-supplied Entity Resolver, then the grammar may actually have been parsed from a location different to the one specified by the XMLGrammarDescription.

Questions here:

1) Is it the responsibility of the XMLEntityResolver implementation to update the XMLResourceIdentifier passed in to reflect where it actually got the document from? If so, this should be documented. If not, something downstream (i.e. XSDHandler in this case) needs to do this if the XMLResourceIdentifier is going to be exposed on an interface as it is with SchemaGrammars.

2) If it is the responsibility of the XMLEntityResolver to update the XMLResourceIdentifier, then  should DOMEntityResolverWrapper do this to ensure that the required behaviour is produced for applications using the DOM 3 LSResourceResolver interface?

The patch I will attach to this issue assumes (for no particularly rational reason) that it is *not* the responsibility of the XMLEntityResolver implementation to update the XMLResourceIdentifer, and alters parseSchema in XSDHandler to update the XSDDescription from the XMLInputSource used to parse the schema.


---------------------------------------------------------------------
JIRA INFORMATION:
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

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira


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