Dick Deneer <[EMAIL PROTECTED]> wrote on 07/10/2006 03:57:46 PM: > Op 10-jul-2006, om 5:40 heeft Michael Glavassevich het volgende geschreven: > > It was implemented in Xerces 2.8.0. If your ErrorHandler has a reference > to the Validator and you query the > http://apache.org/xml/properties/dom/current-element-node property [1] the > Validator will return the current element node that is being visited. > > I just ran a test and it works great!! Thank you > >> Couldn't you just create the Schema from the SchemaFactory using all of >> sources that you would have used to populate the grammar pool? It's true >> that the Schema implementations in Xerces are backed by a grammar pool but >> you really shouldn't be trying to do anything with these grammar pools. >> They are only intended for consumption by the JAXP validator. If you try >> writing to them you'll find three of the four implementations are >> immutable and the fourth is a memory sensitive cache which releases >> grammars to the garbage collector in response to memory demand so the >> grammar you add might get tossed at some point. > > If there is really no other way, than I have to administer all > resources myself. > It also means that they will be compiled again when used in the validator. > But so be it. > >> The Schema returned by SchemaFactory.newSchema() [2] has different >> semantics to the ones returned by the other newSchema() [3] methods. Think >> of the SchemaFactory.newSchema() schema as open, rather than empty. It >> pulls in schema components during validation from the schema locations >> specified in the documents and/or the sources returned by your >> LSResourceResolver if you registered one with the Validator. The Schema >> objects returned by the other newSchema() methods are closed (or fully >> composed). Only the schema components which were loaded by the >> SchemaFactory are used for validation. Your LSResourceResolver won't be >> called during validation and any schema location hints in the document >> will be ignored. > > Ok it is clear to me. But in fact I cannot see why it why the > specification was that way. If you want a "closed" schema the you > also could have returned empty sources in the ResourceResolver. > Maybe it has something todo with "constant behaviour" and thread > savety. Anyway ..
I think the motivation was actually to provide applications with a means for blocking untrusted schemas. A schema location hint in an instance may point to some other schema than the one which specifies the constraints you want to enforce. The "closed" schema gives an application full control over which schema components are used for validation. > I need a open schema because the user may change or add references in the xml. > I was hoping that at least the "open" format SchemaFactory. > newSchema() worked the way as the validator was described in > articles about schema caching ( see http://www-128.ibm. > com/developerworks/xml/library/x-perfap3.html and http://xerces. > apache.org/xerces2-j/faq-grammars.html#faq). and that you easily > could exchange the grammarpool between the DOM level3 api and JAXP. I suppose you could extract the grammar pool from the Schema object and pass that to the DOMConfiguration. > In the last article there is something mentioned about a System property ( > System.setProperty("org.apache.xerces.xni.parser.XMLParserConfiguration", > "org.apache.xerces.parsers.XMLGrammarCachingConfiguration"); but > I guess this cannot be used in relation to the validator and a > specific grammarpool? No. That's just a global way of turning on grammar caching in a parsing context. The grammar pool owned by XMLGrammarCachingConfiguration is shared across all parser instances. > So the between the JAXP validator and the DOM level 3 revalidation > are significant. I think a lot of people have not realized that. > And maybe because I merely work with the last they struck me. I > think the way the caching works there is very elegant. > One last (:)) question about the the grammarpool: when the > LSResolver asks for a resource with systemid x, and I return a > resource with systemid y, the grammarpool stores the returned > resource (y) with systemid x. This is not a bug? I think that was the intended behaviour. The grammar pool is consulted before calling your resolver so will always see the original system ID. >> [1] >> http://xerces.apache.org/xerces2-j/properties.html#dom.current-element-node >> [2] >> http://xerces.apache.org/xerces2- >> j/javadocs/api/javax/xml/validation/SchemaFactory.html#newSchema() >> [3] >> http://xerces.apache.org/xerces2- >> j/javadocs/api/javax/xml/validation/SchemaFactory. >> html#newSchema(javax.xml.transform.Source[]) >> >> Michael Glavassevich >> XML Parser Development >> IBM Toronto Lab >> E-mail: [EMAIL PROTECTED] >> E-mail: [EMAIL PROTECTED] Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: [EMAIL PROTECTED] E-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
