[DFDL-WG] clarification: element properties like nilValue and nilKind on simpleType - scoping rules

Mike Beckerle mbeckerle.dfdl at gmail.com
Fri Apr 28 13:54:50 EDT 2017


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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20170428/da4cac79/attachment.html>


More information about the dfdl-wg mailing list