[jira] [Assigned] (DAFFODIL-2828) Allow relative paths across schemas as schemaLocation for include/import

["Mike Beckerle (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-2828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mike Beckerle reassigned DAFFODIL-2828:
---------------------------------------

    Assignee: Mike Beckerle

> 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
>
> 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)