stevedlawrence opened a new pull request, #1067:
URL: https://github.com/apache/daffodil/pull/1067
We currently resolve include/import schema locations in two different
places, one in the DaffodilCatalogResolver and the other in dsom IIBase.
The logic is not obviously the same, so this adds a new XMLUtils
function specifically for resolving a schemaLocation attribute. The more
complex cases like catalog managers are not implemented here and are
still done in the different classes, but this at least consolidates the
search when catalog manager fails (which is the common case).
This also slightly tweaks the schemaLocation logic to the following
- If a schemaLocation is an absolute URI (i.e. has a scheme) we just
look it up directly
- If a schemaLocation is not absolute and the path starts with a /, then
we first look for it on the classpath. If not found we look for the
absolute path on the file system
- If a schemaLocation is not absolute and the path does not start with a
/, then we resolve the path relative to the importing file. If not
found, we look for the relative path on the classpath absolutely, but
with a deprecation warning.
Note that this deprecates looking up relative include imports on the
classpath. A schemaLocation that is expected to be in different jar on
the classpath should be an absolute path. This removes any ambiguity
about if a file should be resolved relative to the importing schema or
on the classpath. Eventually we should remove the deprecated capability
completely, but most schemas currently depend on this behavior. For
example, many schemas have something like the following:
<import
schemaLocation="org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd" />
But this really should be an absolute path, like so:
<import
schemaLocation="/org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd" />
This also modifies the CLI to have similar logic, where we warn if a
schema path is provided absolutely.
Deprecation/Compatibility:
Resolving relative import/include schemaLocation paths absolutely is now
deprecated and will output a warning, and support may eventually be
removed. For example, a common import is:
<import
schemaLocation="org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd" />
Although this path is relative, previous versions of Daffodil allowed
this to be found on the classpath absolutely, as if it started with a
slash. This behavior is deprecated. If a schemaLocation is expected to
be found on the classpath and not relative to the importing file, then
it should start with a slash, for example:
<import
schemaLocation="/org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd" />
Daffodil still supports the old behavior and will look up relative
schemaLocatin paths absolutely, but will output a schema definition
warning. Future versions of Daffodil may change this to an error.
[DAFFODIL-2840](https://issues.apache.org/jira/browse/DAFFODIL-2840)
*Note that I've left this as two separate commits, one deprecating relative
schemaLocations and one changing all the imports in Daffodil tests. This should
hopefully make review easiser by mainly focusing on the first commit*
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
