The type stMinlength1 is clearly not suitable for many kinds of reuse. Not all top level type defs will be suitable for use as a rep type because they are just incompletely specified. As you point out here, if used without supplying a different lengthKind it will SDE.
This is ok. It is just a schema design error. For a type to be usable as a rep type it has to have enough properties to stand alone. Or am I missing something? Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Sloane, Brandon <bslo...@tresys.com> Sent: Thursday, April 4, 2019 5:42:02 PM To: dev@daffodil.apache.org Subject: Further design difficulties with TypeValueCalculators I spoke with Mike about this issue the other day, but after more work on the implementation, it appears that the issue is more difficult that we had realized. The enum support proposal allows simpleTypes to define mappings between representation values and logical values. Further, this mapping is accessible to DPath functions by specifying the QName of the simple type. This means that we must have a mapping of QName -> TypeCalculator, where TypeCalculator is a property of a GlobalSimpleType. However, in our current implementation, all GlobalSimpleTypes are constructed by inlining them into their element, which means it is impossible to construct a global instance. In an attempt to work around this, I created psuedo-element in the compiler to serve as the element for the global instance to attach to. In the common case, this works. However, consider the following schema (taken from section05/facets/Facets.tdml ): 3897 <dfdl:format ref="ex:GeneralFormat" /> 4207 <xs:simpleType name="stMinLength_1"> 4208 <xs:restriction base="xs:string"> 4209 <xs:minLength value="1" /> 4210 </xs:restriction> 4211 </xs:simpleType> 3963 <xs:element name="e2_2" dfdl:lengthKind="delimited"> 3970 <xs:simpleType> 3971 <xs:restriction base="ex:stMinLength_1"> 3972 <xs:minLength value="2" /> 3973 </xs:restriction> 3974 </xs:simpleType> 3975 </xs:element> Note that, in the global context, we have are using the format ex:GeneralFormat, which defines dfdl:lengthKind="implicit". However, it is a schemaDefinitionError to use stMinLength_1 with dfdl:lengthKind="implicit", because it does not define a maxLength. In theory, this is okay, because it is only ever used by the element e2_2, which defines dfdl:lengthKind="delimited". However, it means that attempting to construct a global instance of this type will fail unless the compiler knows to overwrite lengthKind; and any solution that attempts to solve this by actually overriting troublesome annotations seems fraught with peril. Ultimately, it seems to me that the issue here is the same as our fundamental performance issue of excessive inlining, as constructing a simple type requires the simple type to be inlined in an element. If this is correct, then fixing it would require doing at least part of the performance fix (in particular, fixing it in the DSOM structure) before it is possible to implement the enum support proposal as written (or, find some much more hacky workaround). Any thoughts? Brandon T. Sloane Associate, Services bslo...@tresys.com | tresys.com