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 <http://www.ogf.org/About/abt_policies.php>