The following issue has been updated:
Updater: Lucian Holland (mailto:[EMAIL PROTECTED])
Date: Thu, 17 Jun 2004 6:53 AM
Comment:
Since submitting my original patch I have realised that it doesn't fix all occurences
of this problem; the same thing happens for imported/included schemas as well. Looking
at the issue again, I had second thoughts about messing around in XSDHandler, and
found a somewhat neater patch that could be made to XMLSchemaLoader instead.
Changes:
Attachment changed to diff.txt
---------------------------------------------------------------------
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: Thu, 17 Jun 2004 6:53 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
