Hi Mike I have taken a look at your revised proposal at https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Features+to... . Can you augment the example with use of the simple type by an element? I think this might highlight a problem. Today we allow the DFDL representation properties for a simple element to be split across the element declaration and the (hierarchy) of simple types. Your proposal is allowing the rep type of an element to be other than the allowed set for the simple type of the element. This prevents the combination of rep properties across the element and the simple type. In fact, it means that all type dependent rep properties would have to be carried by the rep type. That's not going to work because of scoping rules - you can't just switch off property applicability. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh@uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 Note: I work Tuesday to Friday From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl@gmail.com> Cc: "dfdl-wg@ogf.org" <dfdl-wg@ogf.org> Date: 04/04/2017 13:42 Subject: Re: [DFDL-WG] Proposed feature: lookup tables via simple type unions Although signed-up to Confluence I couldn't see a way to comment on the proposal there. I'm not comfortable with the proposal. 1) It relies upon validation being enabled, which is an optional feature. There is a long-held principle that switching on validation does not change the behaviour of a parse, but this will do exactly that. [unionMemberSchema] String. For simple element information items, this member contains an SCD reference to the member of the union that matched the value of the element. Empty if validation is not enabled. Empty if the element's type is not a union. 2) DFDL does not allow the concept of an annotation on a simple type that is a union member. We would be allowing that, but with a completely disjoint property set. Unions; the memberTypes must be derived from the same simple type. DFDL annotations are not permitted on union members 3) The proposal does not help the case where I am not using unions but still would like enums translated into meaningful strings, a far more common situation. I think this processing is best left to either an independent post-parse step or a parser extension via a set of non-DFDL annotations. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh@uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: "dfdl-wg@ogf.org" <dfdl-wg@ogf.org> Date: 22/02/2017 17:38 Subject: [DFDL-WG] Proposed feature: lookup tables via simple type unions Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org> A write up of the proposal, which we are prototyping in Daffodil, is here: https://opensource.ncsa.illinois.edu/confluence/display/DFDL/Enumerations+an... This is needed by a number of data formats we are working with where there are large enumerations having as many as 2000 members. Often these enumerations are a mixture where single values correspond to some enumerated strings, and ranges of values correspond to others. Using expressions to translate representation integers into strings is infeasible, as no constant-time case-statement-like construct is available in DFDL. 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@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 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