[
https://issues.apache.org/jira/browse/DAFFODIL-2117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Beckerle updated DAFFODIL-2117:
---------------------------------------
Description:
Adding a new property, given the need to create tunables to require it or not,
provide tunable default value for it or not, etc. is all WAY too hard, error
prone, etc.
If you look at newly created dfdl:emptyElementPolicy property (which should
move to DFDLX namespace per DAFFODIL-2096), the sheer number of files that have
to be touched is way too large.
There's the
* property itself (several changes to XSDs in daffodil-propgen)
* a tunable for requiring it or allowing it to default (dafext.xsd, and
DaffodilTunables.scala)
* a tunable (of option type) for specifying its default value as a tunable.
* a WarnID for issuing warning that it is required but being defaulted
(dafext.xsd and WarnID.scala)
* the code that actually computes the defaulted property (e.g., in
ElementBase.scala)
** a library is needed here, as we do this quite a lot.
** Note: must detect conflict of a specified property with the tunable if they
are in conflict, and issue a warning (this one is a generic TunableBeingIgnored
warning. Phew!)
We should add a generator to daffodil-propgen to generate these files off of
dafext.xsd and place them in daffodil-lib/src_managed:
* DaffodilTunables.scala
* WarnID.scala
Any information, such as things that are to get option types, can be added to
dafext.xsd as annotations on the elements or attributes so that the generator
can find that info there and generate the correct thing.
While we're at it, the documentation for all the tunables, warnIDs, etc. should
be written into dafext.xsd and we should generate
* scaladoc in the generated scala code files
* (if needed) HTML doc for the user-doc on the daffodil user site.
was:
Adding a new property, given the need to create tunables to require it or not,
provide tunable default value for it or not, etc. is all WAY too hard, error
prone, etc.
If you look at newly created dfdl:emptyElementPolicy property (which should
move to DFDLX namespace per another enhancement), the sheer number of files
that have to be touched is way too large.
There's the
* property itself (several changes to XSDs in daffodil-propgen)
* a tunable for requiring it or allowing it to default (dafext.xsd, and
DaffodilTunables.scala)
* a tunable (of option type) for specifying its default value as a tunable.
* a WarnID for issuing warning that it is required but being defaulted
(dafext.xsd and WarnID.scala)
* the code that actually computes the defaulted property (e.g., in
ElementBase.scala)
** a library is needed here, as we do this quite a lot.
** Note: must detect conflict of a specified property with the tunable if they
are in conflict, and issue a warning (this one is a generic TunableBeingIgnored
warning. Phew!)
We should add a generator to daffodil-propgen to generate these files off of
dafext.xsd and place them in daffodil-lib/src_managed:
* DaffodilTunables.scala
* WarnID.scala
Any information, such as things that are to get option types, can be added to
dafext.xsd as annotations on the elements or attributes so that the generator
can find that info there and generate the correct thing.
While we're at it, the documentation for all the tunables, warnIDs, etc. should
be written into dafext.xsd and we should generate
* scaladoc in the generated scala code files
* (if needed) HTML doc for the user-doc on the daffodil user site.
> Generate WarnID.scala and DaffodilTunables.scala off of dafext.xsd
> ------------------------------------------------------------------
>
> Key: DAFFODIL-2117
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2117
> Project: Daffodil
> Issue Type: Improvement
> Components: Front End, Infrastructure
> Affects Versions: 2.4.0
> Reporter: Michael Beckerle
> Priority: Major
>
> Adding a new property, given the need to create tunables to require it or
> not, provide tunable default value for it or not, etc. is all WAY too hard,
> error prone, etc.
> If you look at newly created dfdl:emptyElementPolicy property (which should
> move to DFDLX namespace per DAFFODIL-2096), the sheer number of files that
> have to be touched is way too large.
> There's the
> * property itself (several changes to XSDs in daffodil-propgen)
> * a tunable for requiring it or allowing it to default (dafext.xsd, and
> DaffodilTunables.scala)
> * a tunable (of option type) for specifying its default value as a tunable.
> * a WarnID for issuing warning that it is required but being defaulted
> (dafext.xsd and WarnID.scala)
> * the code that actually computes the defaulted property (e.g., in
> ElementBase.scala)
> ** a library is needed here, as we do this quite a lot.
> ** Note: must detect conflict of a specified property with the tunable if
> they are in conflict, and issue a warning (this one is a generic
> TunableBeingIgnored warning. Phew!)
> We should add a generator to daffodil-propgen to generate these files off of
> dafext.xsd and place them in daffodil-lib/src_managed:
> * DaffodilTunables.scala
> * WarnID.scala
> Any information, such as things that are to get option types, can be added to
> dafext.xsd as annotations on the elements or attributes so that the generator
> can find that info there and generate the correct thing.
> While we're at it, the documentation for all the tunables, warnIDs, etc.
> should be written into dafext.xsd and we should generate
> * scaladoc in the generated scala code files
> * (if needed) HTML doc for the user-doc on the daffodil user site.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
