[
https://issues.apache.org/jira/browse/DAFFODIL-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Thompson closed DAFFODIL-2828.
-----------------------------------
Verified the specified commits (commits
41cab1aa3397595d3c419d986db18ffa453d868a and
531e9a6165247e7a480bcf36f8754ea867471903) are included in the latest pull from
the daffodil repository.
Verified, via review, changes identified in the commits comment were
implemented.
Verified all daffodil subproject sbt test suites executed successfully,
including modified and added tests.
Verified all schemaLocations were updated to be absolute where needed.
> 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)
