Hi, Rajiv, Edwin, Thank you for your reply!
Rajiv Mordani wrote: > If someone sets > setValidating(true) and also sets the schema language then it will use the > schema if available else will use the DOCTYPE declaration in the document > for validating using DTDs. It is very hard (if not impossible) for any parser to implement the above, unless document is parsed twice: first time to find XML Schema and second time if schema is not found to validate against DTD. According to XML Schema specification, the schema might not be available at the root, but can be found for one of the children. In this case, validation attempted for document root will be NONE, but it is NOT a validity error and your document may have a schema even if it was found at the last element in the document. So unless JAXP would like to come up with some mechanism for locating XML Schemas, setting schemaLanguage property should mean that validation must occur against the requested language. One way to solve the problem would be to redefined the JAXP schemaLanguage property in the following way: [[ This property defines the schema language that must be used for validation. The set of possible schema languages include: DTD, XML Schema, RelaxNG, etc. For DTD, the value of this property must be "DTD" string. For all other type of schema languages, the value of this property must be the uri of the schema language specification being used (e.i. the value of the property must be set to http://www.w3.org/2001/XMLSchema for the XML Schema specification). ]] Note: if application sets validation to true, but the property is not specified, it is up to an implementation to decide what to validate against: validation may occur against DTD or XML Schemas or both. The JAXP property must be associated with the parser. Thus, setProperty() (or maybe it should be named setJAXPProperty()) should be on the factory classes (DocumentBuilderFactory and SAXParserFactory). The "schemaLanguage" property will describe the type of parser user gets and the type can not be changed between different parse() calls. This is similar to the way setValidation() is defined in JAXP: user must setValidation() on the factory to get a validating parser. For Xerces implementation that would mean that the parser will be created with different configurations depending on features/properties set on the JAXP factory: > 1) app wants to validate to DTD as before. If no doctypedecl, then > error. On factory, set validation to true and the schemaLanguage property to DTD. In JAXP implementation for Xerces, the parser will be created with StandartParserConfiguration. > 2) app wants to validate to XSD. If no XSD association (either using > doc hint or programmatically) then error. On factory, set validation to true and schemaLanguage property to XML Schema Namespace. In JAXP implementation for Xerces, the parser will be created with DTDXSParserConfiguration. > 3) app wants to validate to DTD or XSD, the case you state On factory, set validation to true. Language property is not specified. For Xerces implementation it would mean that we create a parser with all available validators (currently use DTDXSParserConfiguration). > 4) app wants to validate to both DTD and XSD. As Edwin said, I don't think we had requests to support it, nor we know how to define it. Thus, JAXP should leave it up to the implementation. For Xerces, we kinna combine case (3) and (4): -- if we find DTD we validate against it -- if we don't find DTD, we attempt to validate against XML Schema and report validation errors against it. -- if document has both: DTD and XML Schema, we will report errors against DTD (and possibly against XML Schema) > 5) app wants to validate to RelaxNG Set validation to true, set schemaLanguage property to RelaxNG namespace. Create Xerces parser with RelaxNG validator (this is for the future). I will be sending shortly a note on how we plan to change description of Xerces validation features, and how we would use JAXPs language property. Comments? -- Elena Litani / IBM Toronto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
