The workaround is not legal. The behaviour is (b), as specified in section 8.3 which provides the algorithm for combining properties. In that description, the key word is "applicable".

Regards
 
Steve Hanson

IBM Hybrid Integration, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh@uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890



From:        Mike Beckerle <mbeckerle.dfdl@gmail.com>
To:        "dfdl-wg@ogf.org" <dfdl-wg@ogf.org>, Steve Lawrence <slawrence@tresys.com>
Date:        28/04/2017 18:55
Subject:        [DFDL-WG] clarification: element properties like nilValue and nilKind on simpleType - scoping rules
Sent by:        "dfdl-wg" <dfdl-wg-bounces@ogf.org>




So the nil-related properties are not allowed on dfdl:simpleType annotation elements. As well, the corresponding short-form annotations are not allowed on xs:simpleType elements.

But is this workaround legal?

<dfdl:defineFormat name="nilStuff">
   <dfdl:format nilKind="literalValue" nilValue="-"/>
</dfdl:defineFormat>
...
<xs:simpleType dfdl:ref="tns:nilStuff">
   ....
</xs:simpleType>

You see that I'm not putting the nil properties on a dfdl:simpleType nor in short form. I'm getting them indirectly via a ref.
If this workaround is allowed, then I claim the restriction is pretty meaningless and we should probably drop it.
A variation on this theme: if nilKind and nilValue are defined in the default format surrounding an xs:simpleType, can the element referencing that simpleType pick up these definitions from the default format surrounding the simpleType, or can it only get them its own default format.
Another variation: what about dfdl:occursCountKind. Can I put that in a named format, reference it from an xs:simpleType, and have it seen by an element referencing that simpleType? What about the default-format variation?

I think there are only two stable design points
(a) the restriction is meaningless, the workaround works, and the default format surrounding a simpleType def can contribute "element" centric properties such as nilKind, nilValue, and occursCountKind  to the element referencing the type.
(b) the restriction is enforced and only the properties meaningful to a simpleType can be inherited by an element that references that type.
The workaround above doesn't work. Nor does having nilValue or nilKind as the default format surrounding a simpleType mean anything. They would always be ignored.

I guess there is also this design point:
(c) the restriction prevents direct placement of element-centric properties on dfdl:simpleType or in short form on xs:simpleType, but the workaround works, and default format inheritance from the simpleType's default format would also work.
This last one just seems odd to me. It's a restriction for which the workaround is trivial, so one gains nothing from the restriction.

...mikeb

Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com
Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy
--
 dfdl-wg mailing list
 dfdl-wg@ogf.org
 https://www.ogf.org/mailman/listinfo/dfdl-wg

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU