Hi Mukul, Having read through your e-mail I don't see why you would need a JAXP Schema object in this context.
Consider that when we are checking assertions we are in the process of validating the document. The schema validator is already producing: 1) PSVI for each element and attribute. 2) A grammar bucket containing the "effective" schema which one can convert into an XSModel. So you should be able to put that together programmatically to create a PSVI DOM, and perhaps have the code fetch the XSModel [1] from the root element of that DOM. You shouldn't need to construct any new SchemaGrammars. The ones already in the grammar bucket should be sufficient. Thanks. [1] http://xerces.apache.org/xerces2-j/javadocs/xs/org/apache/xerces/xs/ElementPSVI.html#getSchemaInformation() Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [email protected] E-mail: [email protected] Mukul Gandhi <[email protected]> wrote on 05/18/2009 04:33:44 AM: > Hi Michael, > Thanks for your reply. I'll try your code shortly. > > I am working to construct a Schema (javax.xml.validation.Schema) > object for Psychopath interface. As of now, it seems I would need both > Schema and XSModel (but it seems I may not need, > javax.xml.validation.Schema finally.. please see what I feel, below). > > I have observed that following works fine with Psychopath to enable > schema awareness: > > public static final String DOCUMENT_IMPLEMENTATION_PROPERTY = > "http://apache.org/xml/properties/dom/document-class-name";; > public static final String DOCUMENT_PSVI_IMPLEMENTATION = > "org.apache.xerces.dom.PSVIDocumentImpl"; > > DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); > factory.setAttribute(DOCUMENT_IMPLEMENTATION_PROPERTY, > DOCUMENT_PSVI_IMPLEMENTATION); > factory.setSchema(_schema); // _schema is the Schema object > > DocumentBuilder builder = factory.newDocumentBuilder(); > Document document = builder.parse(in); // 'in' is InputStream for > the source XML > > When Psychopath works with the DOM tree 'document' it is able to > perform schema aware XPath evaluations. > > Now further, we get XSModel as well. > > Psychopath needs XSModel to construct the dynmaic context as below. > > DefaultDynamicContext(XSModel xsmodel, Document doc); > > I observed that only having XSModel doesn't work well with Psychopath. > > What I would try now is: > Construct the PSVI DOM from scratch (using say, createElement calls. > this would be a substitute of builder.parse(in)) and then supply that > along with XSModel to Psychopath. I have to see if this would work. If > this works, then we don't need JAXP Schema object. > > The thing I would like to see working with much eagerness is > constructing XSModel from a sequence of endElement calls (where I > pass, ElementPSVI). I think constructing XSModel may not be as > tendious as I think, because I just need to construct XSModel from > only *one* endElement event (which is for the root node of the DOM > tree). > I am thinking to use the constructor: > > XSModelImpl(SchemaGrammar[] grammars) > > and construct the object, SchemaGrammar using number of addxxx calls > (like, addGlobalElementDecl). > > Let's see how it goes. > > I'll share what I might achieve here. > > On Mon, May 18, 2009 at 12:16 PM, Michael Glavassevich > <[email protected]> wrote: > > Hi Mukul, > > > > What you're attempting to do is already possible: > > > > SchemaFactory sf = > > SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI); > > XMLSchemaFactory xsf = (XMLSchemaFactory) sf; > > > > XSModel xsmodel = ...; > > XSNamespaceItemList nsItemList = model.getNamespaceItems(); > > Grammar[] grammars = (Grammar[]) > > nsItemList.toArray(new Grammar[nsItemList.getLength()]); > > XMLGrammarPool pool = new XMLGrammarPoolImpl(); > > pool.cacheGrammars(XMLGrammarDescription.XML_SCHEMA, grammars); > > Schema s = xsf.newSchema(pool); > > > > though I thought that Psychopath took XSModel as input. Or is thisnecessary > > for something else? Saxon perhaps? > > > > Thanks. > > > > Michael Glavassevich > > XML Parser Development > > IBM Toronto Lab > > E-mail: [email protected] > > E-mail: [email protected] > > > -- > Regards, > Mukul Gandhi > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
