[
https://issues.apache.org/jira/browse/DAFFODIL-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Beckerle updated DAFFODIL-2536:
------------------------------------
Description:
(Copied from section _Refactoring for Separable Runtimes/Back-ends_ on the wiki
page:
[https://cwiki.apache.org/confluence/display/DAFFODIL/Roadmap+for+Upcoming+Releases])
Daffodil's layering structure is not right. People want to treat the daffodil
schema compiler as a service that starts with a DFDL schema and creates the
optimized intermediate objects that a runtime backend then converts into
runtime objects (Runtime1), generated code (codegen-c), or other formal
artifacts. One should be able to do this from an outside application of
Daffodil, not be adding things into Daffodil. Today you can't do this.
Fixing this requires flipping the layering structure of Daffodil, so that
daffodil-core, which contains the schema compiler, is split out from the API
for generating an executable artifact. The schema compiler should be a library
called from a higher layer.
The Daffodil API may need to evolve substantially to accommodate this. The
notion that the Daffodil Compiler creates a ProcessorFactory which creates a
DataProcessor is fundamentally flawed with respect to the way people need to
use parts of Daffodil, and to decoupling runtimes/back-ends from the rest of
Daffodil.
As an example, there are many ETL and EAI tools for transforming data. They
each have their own ad-hoc format description language. A natural thing to do
is to use Daffodil's compiler to convert from DFDL into the format description
of one of these other ETL tools. This should be doable by reusing Daffodil's
schema compiler to do all the checking associated with DFDL schemas, and to
lower the representation to the optimized "Gram" objects that effectively
represent the compiler output. A runtime, or converter tool, consumes this
"Gram" object representation and outputs whatever artifact is needed.
was:
See topic _Refactoring for Separable Runtimes/Back-ends_
on the wiki page:
https://cwiki.apache.org/confluence/display/DAFFODIL/Roadmap+for+Upcoming+Releases
> Refactoring for Separable Runtimes/Back-ends
> --------------------------------------------
>
> Key: DAFFODIL-2536
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2536
> Project: Daffodil
> Issue Type: Improvement
> Components: Back End, Front End
> Affects Versions: 3.1.0
> Reporter: Mike Beckerle
> Priority: Major
>
> (Copied from section _Refactoring for Separable Runtimes/Back-ends_ on the
> wiki page:
> [https://cwiki.apache.org/confluence/display/DAFFODIL/Roadmap+for+Upcoming+Releases])
> Daffodil's layering structure is not right. People want to treat the daffodil
> schema compiler as a service that starts with a DFDL schema and creates the
> optimized intermediate objects that a runtime backend then converts into
> runtime objects (Runtime1), generated code (codegen-c), or other formal
> artifacts. One should be able to do this from an outside application of
> Daffodil, not be adding things into Daffodil. Today you can't do this.
> Fixing this requires flipping the layering structure of Daffodil, so that
> daffodil-core, which contains the schema compiler, is split out from the API
> for generating an executable artifact. The schema compiler should be a
> library called from a higher layer.
> The Daffodil API may need to evolve substantially to accommodate this. The
> notion that the Daffodil Compiler creates a ProcessorFactory which creates a
> DataProcessor is fundamentally flawed with respect to the way people need to
> use parts of Daffodil, and to decoupling runtimes/back-ends from the rest of
> Daffodil.
> As an example, there are many ETL and EAI tools for transforming data. They
> each have their own ad-hoc format description language. A natural thing to do
> is to use Daffodil's compiler to convert from DFDL into the format
> description of one of these other ETL tools. This should be doable by reusing
> Daffodil's schema compiler to do all the checking associated with DFDL
> schemas, and to lower the representation to the optimized "Gram" objects that
> effectively represent the compiler output. A runtime, or converter tool,
> consumes this "Gram" object representation and outputs whatever artifact is
> needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
