Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EclipseLink/Development/ProjectXMLSchemaValidation"
(→Schema Validation) |
(→Schema Validation) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
very different results. Of specific interest is the use of <tt>org.xml.sax.EntityResolver</tt>'s to manage | very different results. Of specific interest is the use of <tt>org.xml.sax.EntityResolver</tt>'s to manage | ||
the lookup of xsds. The callback is: | the lookup of xsds. The callback is: | ||
| − | <source lang="java"> | + | <source lang="java">public InputSource resolveEntity(String publicId, String systemId) throws SAXException, IOException</source> |
| − | public InputSource resolveEntity(String publicId, String systemId) throws SAXException, IOException | + | |
| − | </source> | + | |
For example, the Oracle V2 XML Parser populates the <tt>systemId</tt> argument with a relative-path to | For example, the Oracle V2 XML Parser populates the <tt>systemId</tt> argument with a relative-path to | ||
the <tt>xsd</tt> directory in the <tt>eclipselink.jar</tt> file; however, the Xerces parser provided | the <tt>xsd</tt> directory in the <tt>eclipselink.jar</tt> file; however, the Xerces parser provided | ||
| − | with Sun's JDK 1.5 populates it with a fully-resolved path. In addition, if the schema to-be-resolved | + | with Sun's JDK 1.5 populates it with a fully-resolved path. In addition, if the schema-to-be-resolved |
| − | imports another schema, then this second-level of resolving does not work with either parser. | + | imports another schema (<tt>toplink-object-persistence_1x_y_z.xsd</tt> imports <tt>object-persistence_1_0.xsd</tt>), |
| + | then this second-level of resolving does not work with either parser. | ||
| + | |||
| + | === Requirements for Schema Validation === | ||
| + | There does not appear to be a record of a user-driven requirement to perform schema validation on Project XML. | ||
| + | Therefore, we should fix the current EclipseLink to ''not'' perform validation by default and enter an Enhancement | ||
| + | Request (ER) for a new feature. It should be debated upon its merits and scheduled as normal. | ||
Latest revision as of 16:12, 28 July 2008
Schema Validation
EclipseLink 'native' Project XML is described in the EclipseLink jar in xsd\eclipselink_persistence_map_1.0.xsd, along with the previous TopLink versions in xsd\toplink-object-persistence_1x_y_z.xsd.
When a Project XML file is read in, EclipseLink attempts to validate it against the above schemas. However, schema validation in Java has mostly been a 'hit-&-miss' affair, with different XML parsers providing very different results. Of specific interest is the use of org.xml.sax.EntityResolver's to manage the lookup of xsds. The callback is:
public InputSource resolveEntity(String publicId, String systemId) throws SAXException, IOException
For example, the Oracle V2 XML Parser populates the systemId argument with a relative-path to the xsd directory in the eclipselink.jar file; however, the Xerces parser provided with Sun's JDK 1.5 populates it with a fully-resolved path. In addition, if the schema-to-be-resolved imports another schema (toplink-object-persistence_1x_y_z.xsd imports object-persistence_1_0.xsd), then this second-level of resolving does not work with either parser.
Requirements for Schema Validation
There does not appear to be a record of a user-driven requirement to perform schema validation on Project XML. Therefore, we should fix the current EclipseLink to not perform validation by default and enter an Enhancement Request (ER) for a new feature. It should be debated upon its merits and scheduled as normal.