...
It is simply basic software engineering that large and complex things need to be named and reused, not duplicated. DFDL as a language should have features to allow good basic practices to be followed.
Complex Type Derivation - Allowing Properties on ComplexType Definitions
| Code Block |
|---|
<xs:element name="foo" type="myComplexType" dfdl:ref="complexTypeStuff"/> |
Complex type elements often want to have different default properties than simple types. E.g., dfdl:lengthKind might be explicit for simple types, but implicit for complex types. This makes putting a mixture of simple and complex type elements in the same file painful. If you have a type that you reuse many times, every time you reference the type, you have to add some properties (like dfdl:lengthKind="implicit").
This would be ok, except that you cannot move these added properties down onto the complex type definition. You can with simple types, as the properties on the simple type are combined with those of the element. But complex types don't offer this in DFDL v1.0. This makes you want to use element references a lot in order to hide this noise, but those require global element names, which interferes with namespace management and the very desirable elementFormDefault='unqualified'.
For DFDL 2.0 we should fix these annoyances. We should allow complex type derivations, combining properties on them in the exact same manner as we do for simple types. We should allow properties to be annotated on a complex type definition and for those to be combined with those on an element referencing that type.
Allowing Properties on Group Definitions and Group References
And... exactly the same thing for groups and group references. We don't allow these to be annotated currently. We should.