Agreed to drop dfdl:property() from 1.0. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 23/05/2012 18:19 ----- From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Steve Hanson/UK/IBM@IBMGB Cc: dfdl-wg@ogf.org, Tim Kimber/UK/IBM@IBMGB Date: 19/04/2012 23:35 Subject: Re: [DFDL-WG] String literal syntax for hexBinary ?? - dfdl:property semantic ... But are we all happy that the result of dfdl:property when the property value is an expression, is the result of executing that expression? How complicated is that going to make implementations? Well, what is the use case for dfdl:property() at all? One example would be where there is a choice, and different record formats as the alternatives of the choice depending on the length or number of occurrences of some element. So a discriminator expression would refer to dfdl:property("length",...) for example. However, I do believe we could drop dfdl:property(....), and just say "use variables if you want this behavior". E.g., if I have dfdl:length="{....}" then as the schema author I can always introduce a variable myLen, set its value to that of the expression, change to dfdl:length="{ $myLen }" and where I would have used dfdl:property("length", path), instead just reference the variable as $myLen. I will have to define the variable, and use newVariableInstance so that the variable goes into and out of scope appropriately just like a property value does, but this isn't horribly complex. ...mikeb 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