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=5070>. 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=5070 startEntity needs parameter for actual URI Summary: startEntity needs parameter for actual URI Product: Xerces2-J Version: 2.0.0 [beta 2] Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: XNI AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I believe org.apache.xerces.xni.XMLDocumentHandler.startEntity should have an additional actualURI parameter giving the URI actually used to retrieve the entity. This is the URI that would be the base URI for URI references occurring in the entity. It is different from the baseSystemId parameter which gives the base URI of the entity containing the declaration of the entity being started. At the moment I am working around this by expanding systemId relative to baseSystemId and using that as the actualURI. This is unsatisfactory for a couple of reasons. Firstly, the expansion process is non-trivial (see XMLEntityManager.expandSystemId); Xerces has already done it; it is silly to require applications to redo it. Secondly, in the presence of HTTP redirection or an entity resolver that uses catalogs to resolve public IDs, the actualURI used may be different from the result of the expansion. This second reason is not applicable if you take the view that the systemId/baseSystemId parameters correspond to the URI used for retrieval not to the declared systemId; but that seems at odds with the publicId parameter (which presumably corresponds to the declaration). There's a similar issue with XMLInputSource: when you supply an InputStream you need to specify what should be used as the base URI for that InputStream; this is not the same as the baseSystemId which is the base URI of the entity containing the declaration of the systemId. There's also a similar issue with XMLLocator. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
