I haven't fully implemented it since I didn't want to go much farther until the
direction was decided, but I think these are the classes that cannot currently
resolve properties but can in theory throw a warning:
DFDLAssert
DFDLChoice
DFDLDefineEscapeScheme
DFDLDefineEscapeSchemeFactory
DFDLDefineFormat
DFDLDefineVariable
DFDLDiscriminator
DFDLElement
DFDLEnumerationFactory
DFDLEscapeScheme
DFDLFormat
DFDLGroup
DFDLNewVariableInstance
DFDLProperty
DFDLSchemaFile
DFDLSequence
DFDLSetVariable
DFDLSimpleType
EnumerationDef
GlobalChoiceGroupDef
GlobalComplexTypeDef
GlobalElementDecl
GlobalSequenceGroupDef
GlobalSimpleTypeDef
GroupRefFactory
Import
Include
LocalComplexTypeDef
LocalSimpleTypeDef
Restriction
Schema
SchemaDocument
SchemaSet
Union
XMLSchemaDocument
So all the dfdl:* elements, global declarations, and then a few normal XS
elements.
Feels like maybe the right approach is all DSOM schema components look for an
attribute that be locally defined on the component, so no normal DFDL property
resolution. And that value propagates to the grammar/runtime data/parsers/etc
that are ultimately created from that component.
On 2024-09-12 03:59 PM, Mike Beckerle wrote:
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?
