[
https://issues.apache.org/jira/browse/DAFFODIL-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Lawrence resolved DAFFODIL-2828.
--------------------------------------
Fix Version/s: 3.5.1
Resolution: Fixed
Fixed in commits 41cab1aa3397595d3c419d986db18ffa453d868a and
531e9a6165247e7a480bcf36f8754ea867471903
> Allow relative paths across schemas as schemaLocation for include/import
> ------------------------------------------------------------------------
>
> Key: DAFFODIL-2828
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2828
> Project: Daffodil
> Issue Type: Improvement
> Components: Front End
> Affects Versions: 3.5.0
> Reporter: Mike Beckerle
> Assignee: Mike Beckerle
> Priority: Major
> Fix For: 3.5.1
>
>
> The current way Daffodil deals with schemaLocation for include/import is
> useful and powerful for composing assembly DFDL schemas from component DFDL
> schemas.
> However, it is non-standard. It makes it hard for other tools to re-use DFDL
> schemas without having to edit them.
> Other XML Schema processing software generally does not do any class-path
> searching for components, and cannot deal with jar files.
> Sometimes that software can be adapted by supplying the Daffodil resolver,
> which makes it handle schemaLocation the same way as Daffodil.
> But other kinds of software either don't offer this, or are written in
> technologies that can't link against the Daffodil resolver.
> The lowest common denominator for schemaLocation handling that all tools seem
> to support is
> 1) assume all files are in the same file tree
> 2) schemaLocation is interpreted as a relative path from the current file
> which contains the include/import.
> This means when one schema (let's say a/b/foo.dfdl.xsd) wants to refer to
> another schema (c/d/bar.dfdl.xsd), it does so by using a schema location like
> "../../c/d/bar.dfdl.xsd". That is, there are relative path steps up to the
> root, then the path down to the other schema file.
> To be consistent with this, daffodil has to try to resolve the schemaLocation
> as a relative path (it does this today), and only if that fails does it try
> to resolve against the various jars/dirs on the classpath (it also does this
> today). The change required is that it needs to try this latter resolution by
> first stripping off all upward path steps from the start of the
> schemaLocation. Today in Daffodil you cannot have these upward path steps in
> your schemaLocation for an inter-schema reference. Daffodil will fail to
> resolve such a path.
> This is consistent with current schemaLocations in our DFDL schemas, because
> we either provide a relative path, or an absolute path from the root. So
> nothing should break.
> But it would enable DFDL schema authors to put the upward relative path steps
> in, which allows the schemas to be used, unmodified, by just unzipping all
> classpath jar files, and copying all classpath directories, onto the same
> single file-system root point. The single file tree that results would behave
> as a combined schema.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
