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

[Steve Hanson]

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 at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890



From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>, Steve Lawrence 
<slawrence at 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 at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20170430/66224f15/attachment.html>