Dear, Maybe a little background first: I am in process of delivering a XOM-like java library to XMLSchema called 'endymion', that will be released under LGPL as part of the 'narcissus'-project. The goal of the API is to offer a heavily typed, java-like and simple access to the information embedded in an XMLSchema.
At first I started of with parsing XMLSchema myself, but surrendered after a while becaause of the complexity it brough upon combined with the apparent liberal interpretations of the XMLSchema spec of some other parsers. I decided on the XMLSchema infoset model (org.apache.xs.*) in Xerces because it is light, has active developers and tries to adhere to specs. But, of course, I am encountering some issues (let's call them challenges :-)) * I would like to validate XML to specific complex types in XMLSchema's. (so without them being declared as XMLSchema instances...) I would also like to be able to validate in memory DOM document trees / XOM document trees / JDOM document trees / SAX parse events with a non Xerces parser /... I think I am familiar enough with the Xerces internals to know that this should not be that difficult. For example for the SAX Parser I would only need to simulate an XNI-pass by making an adapter class that implements DefaultHandler and translates all events to a XMLDocumentValidator as if in a a XNI-pipeline. This adapter class seems to be pretty generic (can make all XNI - XMLDocumentHandler act upon SAX events except for XNI events) that I was wondering if it didn't already exist, or if somebody could give me some tips with regards to this. * I see that in CVS there have been several changes / updates with regards to the visibility of fields and methods in several API classes. I was wondering if there is a certain goal or reason for permorming these changes and when they are finished / released. It would be really cool to have some public hooks into the org.apache.xerces.impl.dv.xs.* - value-classes to be able to access the actual values of DecimalDV and others. I am very eager to contribute back any bug fixes / changes that I will develop so even if you only have some guidelines as opposed to full fledged solutions I will be very happy... Mik --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
