[
https://issues.apache.org/jira/browse/DAFFODIL-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860257#comment-16860257
]
Steve Lawrence commented on DAFFODIL-2096:
------------------------------------------
As I started implementing the extensionsEnable feature, I started wondering
what woulld be the use case for a user to be able to enable or disable certain
extensions but not others? It seems to me either a user wants the full
capabilities of Daffodil (all extensions enabled), or they want to be fully
compliant with DFDL v1.0 (all extensions disabled). Or maybe another option
would be fully compliant with IBM DFDL (e.g. error on things like
outputValueCalc).
Perhaps instead of per-extension tunables, what we really want is a
compatability mode tunable that either enables/disables features or changes
property defaults based on what the user wants to be compatible with? I'm not
sure if something like "strict" vs "lax" compatability mode makes sense, or if
more specific modes like "daffodil" vs "dfdl1.0" vs "ibm" make sense. I'm
hesitent to make an "ibm" compatability mode just because trying to track down
everything that doesn't work with ibm and disable it could be a big task.
Continuing this though process, maybe different compatability modes are really
just different sets of tunable values? So maybe all configurability should
still be determined by tunables like it is now, but we add some way to set a
bunch of tunables to a certain set of values? I'm not exaclty sure how that
would blend in with our tunable generator, since presumably we would also want
to generate these compatability tunable sets as well. And how would one
speficiy this compatability mode? Is it a meta-tunable that just sets a bunch
of other tuanbles when set?
> Add dfdlx extensions namespace prefix. Convert existing extensions to this
> namespace.
> -------------------------------------------------------------------------------------
>
> Key: DAFFODIL-2096
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2096
> Project: Daffodil
> Issue Type: New Feature
> Components: Front End
> Affects Versions: 2.3.0
> Reporter: Michael Beckerle
> Assignee: Steve Lawrence
> Priority: Major
>
> Turns out Daffodil is not the only DFDL project creating extensions to DFDL.
> In order that schemas that are portable/non-portable can be distinguished,
> the DFDL workgroup has decided to bless a specific extension namespace, which
> is the current dfdl namespace plus the word "extensions".
> All the properties that we've added to dfdl that are beyond the DFDL v1.0
> spec should appear in this new dfdlx namespace instead.
> When they appear inside a dfdl:format or other long-form annotation, they
> would need the dfdlx namespace prefix, unlike standard dfdl properties which
> omit this prefix when used in long-format.
> When referenced from <dfdl:property name="dfdlx:newProp">.... they would use
> a QName, not just the bare name as DFDL v1.0 properties do.
> This same new prefix should be used for extension functions we add to DPath.
> Since this change would break existing Daffodil schemas, it is sensible for
> both the current and new namespace both work for a while (co-exist) based on
> a tunable flag, and we issue a (suppressable) warning about the older style.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
