http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2510
*** shadow/2510 Tue Jul 10 16:41:39 2001
--- shadow/2510.tmp.9531 Wed Jul 11 07:55:31 2001
***************
*** 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 |
+----------------------------------------------------------------------------+
--- 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 |
+----------------------------------------------------------------------------+
***************
*** 142,144 ****
--- 142,180 ----
But the code using that also fails to use the ErrorHandler of the current
parser if one is available.
+
+
+ ------- Additional Comments From [EMAIL PROTECTED] 2001-07-11 07:55 -------
+ Lots to respond to:
+
+ 1. The reason your ErrorHandler was picked up by your parser object when
+ declared on an XMLReader object (yes these are objects...) is that a SAX2
+ adapter is used to transform a pre-existing XMLReader into a Parser when the
+ getParser method is called. This I must admit I did not know.
+
+ 2. The DOMParser used in traverseImportDecl isn't responsible for resolving
+ schemas referred to by the schema it's parsing; this is why it gets a dummy
+ entityResolver. (you could argue ione should be set actually). Basically the
+ DOMParser simply parses the schema file into a DOM that the TraverseSchema
+ class then operates on; it's up to TraverseSchema to figure out what schemas it
+ references and pull them in using the EntityResolver it has access to.
+
+ 3. Once I made all references relative (i.e., got rid of the vnd.sun.* names
+ in your Test program and simply used a local file name, the fild-not-found
+ warning went away. I don't know sufficiently well how Java uses these package
+ names to comment on why this might be the case.
+
+ 4. That isn't to say the errors went away: we have some problems with these
+ files that relate to the xml namespace prefix.
+
+ 5. We don't actually use the structures.dtd and datatypes.dtd that are in the
+ Xerces package; we have custom facilities for validating schemas. To validate
+ a schema, you simply write an instance document for it and feed that to the
+ parser; if there are errors in the schema they will be detected then. These
+ two .dtd files should be removed from the parser package.
+
+ So there are some bugs to be pointed out here for sure, but they don't have to
+ do with the traverseImportDecl method directly.
+
+ Cheers,
+ Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
