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.

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