Hi Berndt, Hopefully this will become more intelligible if we move it to the list. : -) ! 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 All right, I'm convinced. Change made in CVS. ! 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. ??? Basically, if Xerces sees a schemaLocation in an instance document and it resolves to an XML document, it will take that to be a schema and squeal if it isn't. We don't need (and I don't believe should have to have) a DOCTYPE definition to tell us anything... ! ! 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. The schema for schemas is one of the parts of the Schema specifications that we consulted when we developed the schema implementation. It isn't sufficient to validate schema documents on its own, but using it to help validate documents must be slower than building a custom engine for validating schema docs. That's why we've gone down the road of building the capability to validate schemas right into the parser, not relying on any DTD's or schemas to help; it just speeds things up. So that's why the files in question are now gone from CVS: we weren't using them and they were confusing people. As to schemas we can't validate: you're right, we certainly have problems with xml.xsd. I think that's because we don't understand that "xml" is implccitly bound to a particular namespace; I still have to look up whether this is indeed expected of us. (Anyone know offhand?) If it is then we'd better change that behaviour... If you have other schemas that don't validate, we'd love to have access to them, especially if you can whittle them down to show precisely where we're going off the rails. That's how we'll become better at validating schemas. :-) ! 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. That's not a very easy problem to fix, unfortunately. Basically the original ErrorHandler gets wrapped in another class so that we can use a message infrastructure; but this means that, when we spawn new parsers, we don't have access to that original object anymore. Definitely something to consider in the Xerces 2 redesign, but I'm not sure the rather considerable effort this would involve is justifiable in Xerces-1. ! 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 ? Yup. :-) Hope that helps, Neil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
