This is related to the previous thread with the subject "Further design difficulties with TypeValueCalculators". I believe I have solved the main issue of that thread by computing attributes that do not depend on the context in the SimpleTypeDefFactory instead of the instance class [0].
However, there is still an issue where I am changing the behaviour of Daffodil to compile aspects simpleTypes regardless of if they are used or not. We avoid the previous problem by making these aspects only those whose correctness does not depend on the local context. However, there is still an issue where if an unused simpleType is just plain broken, it will now emit an SDE. For instance, in section05/facets/Facets.tdml we have the following schema: 4856 <xs:simpleType name="enum_st1"> 4857 <xs:restriction base="xs:string"> 4858 <xs:enumeration value="Trout" /> 4859 <xs:enumeration value="Bass" /> 4860 <xs:enumeration value="Catfish" /> 4861 </xs:restriction> 4862 </xs:simpleType> 4880 <xs:simpleType name="enum_st4"> 4881 <xs:restriction base="ex:enum_st1"> 4882 <xs:enumeration value="Trout" /> 4883 <xs:enumeration value="Bass" /> 4884 <xs:enumeration value="Carp" /> 4885 </xs:restriction> 4886 </xs:simpleType> As test case facetEnum06 verifies, enum_st4 is broken because "Local enumerations must be a subset of base enumerations" The issue I am now running into is that all tests that use that schema are now failing due to this, even if they do not actually use enum_st4. Abstractly, I don't mind calling this acceptable behaviour, as there is an SDE in any schema containing enum_st4, even if the original implementation ignored it; and I don't mind updating the relevent test files to isolate these broken types in their own schema, but I wanted to verify that it is okay to make this sort of backwards incompatible change. [0] This involved a fair amount of refactoring. There is more refactoring that can be done along these lines (which I believe will help with our performance issue), but I only did what was needed to support the functionality I am adding. Regards, Brandon T. Sloane Associate, Services [email protected] | tresys.com
