[
https://issues.apache.org/jira/browse/DAFFODIL-2096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16860262#comment-16860262
]
Brandon Sloane commented on DAFFODIL-2096:
------------------------------------------
>From a language design standpoint, it makes sense to allow extensions to be
>enabled seperatly as a way of users documenting/enforcing that they are only
>using a limited number of non-standard features; although I do not think the
>DFDL standard is entrenched enough (nor the extensions complicated enough) to
>justify this.
I think keeping them as seperate tunables with some pre-set tunable bundles is
the way to go. Many of these extensions are experimental, which means we might
decide we want to depreciated them in the future. Keeping the tunables seperate
would allow us to actually disable them in a new bundle while still allowing
users to take advantage of features introduced in the new bundle and continue
using the depreciated extension.
As far as the implementation, I would say the compatability mode is a
completely new option, which has the effect of setting all of the tunable
values it defines. Then, any explictly set by the user tunable could override
the setting from the compatability mode.
> 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)
