One thought is that this doesn't want to be "dfdlx" as really this is a daffodil-specific thing, forever. It's not an extension to DFDL intended to be put forward for standardization. So, I think this should be "daf:" prefix, bound to a daffodil namespace.
Other than complex type definitions, what are other places where these annotations would be helpful where they are not currently allowed? I think adding the ability to put properties on complex type definitions, but then only restricting it to specific properties should be possible. One important thing is the way property combining works. A property expressed on an element ref cannot also be expressed on the global element decl, nor the type definition. You can't override explicit properties, only lexically inherited properties. Is that the behavior we would want for this new property? On Thu, Sep 12, 2024 at 1:58 PM Steve Lawrence <slawre...@apache.org> wrote: > > DAFFODIL-2638 asks for a new feature to be able to selectively suppress schema > definition warnings in specific locations by adding inline annotations to the > schema. This is useful since some schemas will always create warnings and we > don't necessarily want to carry around a config or tunables to suppress them. > Also, using config/tunables suppresses warnings globally, but ideally they > would > only be suppressed in specific places to acknowledge the warning is is > expected. > > I started implementing this and the initial approach was to add a new > extension > property (e.g. dfdlx:suppressSchemaDefinitionWarnings) that could be placed on > any schema component, and would be used to suppress any warnings where that > component is the context. > > The issue with this is it makes use of normal property lookup logic, but some > contexts where warnings can be generated cannot lookup properties (e.g. global > complex element definition). In some cases the warnings might be so early in > the > schema compilation process that resolution traits might not even be available. > So I started this to discuss if there are any ideas for how this feaure might > wok. > > Do we add the ability for these components (like global complex type > definition) > to resolve properties? > > Do we manually parse XML attributes and not use normal property resolution in > these cases? So we could use the property, but not inherit default properties > or > refs, for example. > > Is this just a limitation, and some warnings just can't be suppressed inline? > > Do we need a lower level syntax that doesn't make use of properties at all, > maybe something like COVERAGE-OFF/ON comments that we use to disable code > coverage? Maybe something that can exist and be parsed even before DSOM is > even > fully built? > > Thoughts?
