http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2510
*** shadow/2510 Wed Jul 11 07:55:31 2001
--- shadow/2510.tmp.17672 Thu Jul 12 00:34:31 2001
***************
*** 2,9 ****
| traverseImport does not use parsers EntityResolver |
+----------------------------------------------------------------------------+
| Bug #: 2510 Product: Xerces-J |
! | Status: RESOLVED Version: 1.4.1 |
! | Resolution: INVALID Platform: All |
| Severity: Major OS/Version: Other |
| Priority: Other Component: Schema-Structures |
+----------------------------------------------------------------------------+
--- 2,9 ----
| traverseImport does not use parsers EntityResolver |
+----------------------------------------------------------------------------+
| Bug #: 2510 Product: Xerces-J |
! | Status: REOPENED Version: 1.4.1 |
! | Resolution: Platform: All |
| Severity: Major OS/Version: Other |
| Priority: Other Component: Schema-Structures |
+----------------------------------------------------------------------------+
***************
*** 177,180 ****
do with the traverseImportDecl method directly.
Cheers,
! Neil
--- 177,273 ----
do with the traverseImportDecl method directly.
Cheers,
! Neil
!
! ------- Additional Comments From [EMAIL PROTECTED] 2001-07-12 00:34
-------
! Lots to comment on too:
!
! for 2.) The DOMParser used in traverseImport has the xerces parser feature
! http://xml.org/sax/features/external-parameter-entities set to it�s default
! value true. Thus for any schema with a doctype declaration eg.
!
! <!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "XMLSchema.dtd" >
!
! it will try to load the DTD. The dummy Resolver set at that DOMparser isn�t
! able to provide the DTD as it only provides dtd�s of an older version of the
! XML Schema specification. Add the following statement at the begin of the
! resolveEntity in the TraverseSchema.java�s Resolver and you will see what i
! mean.
!
! System.err.println("TraverseSchema resolveEntity publicId="+publicId+",
! systemId="+systemId);
!
! IMHO it�s correct to load the DTD here (we are validating!) but the DOMParser
! should use a resolving method that can provide it. Thus the dummy provider
! should be modified to call the Resolver set at the parser if it can not provide
! it itself and additionally it would also be a good idea to update it to being
! able to provide the current DTD�s itself, of course.
!
! for 3.) What happens if you do such modification is the following: The Resolver
! set at the DOMHandler is still not able to provide the DTD. Any Resolver set at
! the parse in use is still not called. But as the Resolver set at the DOMParser
! returned null now Xerces default entity resolving routines are called. Luckily
! due to the modification the XML Schema that was traversed came from a location
! those default routines can handle. Essentially after such modification a later
! effect of the problem is not visible because it is circumvented by the parsers
! default routines now loading the DTD. But the reported problem will still be
! shown: The Debug printout in the supplied EntityResolver is not there for this
! DTD. The supplied EntityResolver is not called for all entities that need to be
! resolved.
!
! What I want to stress here is that the traversed Schemas will be loaded by the
! entityResolver set at the current parser if it provides them while ANY(!)
! loading of external referenced entities used in that Schema will not use the
! entityResolver set at the parser. This includes but is not limited to the
! loading of a DTD used in a DOCTYPE declaration of a Schema.
!
! Why would I want to be able to load Schemas and external entities they
! reference from locations not using the http:// scheme, that�s simple because
! it�s faster to cache them locally somehow.
!
! Is this allowed ?
!
! Yes, the XML namespace specification and XMLSchema specification explicitly
! mention that the namespace must not necessarly be identical with the physical
! location of the resource.
!
! Why can�t I always do this it by using file:// URL�s, because the parsing might
! be done in an environment where access to java.io.File routines is prohibited.
! Eg. the servlet Specification only guarantees access to one temporary directory
! for everything other file access the webserver can throw a security exception.
! Simpilar things happen for java code executed in a J2EE Application server.
!
! Xerces is one of today�s most advanced XML parser, the advanced features
! shouldn�t be limited to toy environments.
!
! The setEntityResolver at the XMLReader allows we to customize the parser to use
! my own method of providing resources. It�s not important that you understand
! how the specific method used in my testcase to provide resources works (loading
! them from java packages). I could as well have them load them from a database
! or using JNDI or whatever. What is important is that whenever resources
! referenced by other resources are loaded this customized loading method should
! consulted first and not ignored.
!
! for 4.) OK, seems that those are different problems that ought to be reported
! as annother bug.
!
! for 5.) No i don�t think they should be removed, they shoud be updated to the
! ones included in my testcase ;-) As this would enable the Schema validator to
! be able to handle schema documents that use a DOCTYPE declaration to declare
! that they are schema documents, see above.
!
! Sure fixing this problem would most likely also get the code a major step
! further in being able to validate Schemas, but the scope of the problem is
! broder. The XML Schema Schema is just one in a dozen of Schemas that can not be
! validated in some situations. And the fact that there is a workaround for the
! sub-problem of validating schema documents does not solve the general problem.
!
! Misc.) One related bug that has been pointed out and has also to do with the
! traverseImport method directly is that some errors during traversImport are
! printed to stderr instead of calling the ErrorHandler supplied to the parser.
!
! Meta.) I am not very familar with the procedures used in the Xerces-J open
! source community yet. Should we continue this discussion in the bugtracker or
! should we move it to the developer mailing list ?
!
!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
