DFDL: Action 027 - rework of property precedence - plus issues arising
I've created a separate property precedence for each schema object that can carry non-scoping DFDL properties (attached for review). The following issues were noted: 1) Missing property dfdl:textBooleanJustification - similar properties exist for string, number and calendar types. 2) What is the rule when the same DFDL properties occur on a xs:simpleType and a xs:element that uses that type? Does this work a) like element/group references (ie, properties combined with element winning) or b) like complex element and its sequence (ie, element and simpleType are considered separate objects)? I don't think section 10 covers this case. 3) Should we allow the DFDL nil & default control properties on a simple type? xs:nillable and xs:default are element only attributes in xsd. Spec currently allows this. 4) Should we allow DFDL occurs properties on global elements? Whether something repeats is a particle thing. Spec currently allows this. (IBM's WTX and MRM don't allow this). 5) Missing work item to get BiDi properties into shape and incorporated into spec. Should these be grouped, like escape scheme, calendar scheme, etc? Do they apply to calendar and number types? 6) Should dfdl:integerBooleanXXXRep be renamed dfdl:binaryBooleanXXXRep ? 7) We might want to reconsider the name of the new flag dfdl:initiated - it could be read that the xs:sequence itself is initiated rather than its children. 8) Should dfdl:initiated also apply to xs:choice? 9) Draft 33 property precedence had dfdl:outputLengthCalc - but that is not in the spec anywhere else? Regards Steve Hanson Programming Model Architect WebSphere Message Brokers Hursley, UK Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 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
Steve Comments I don't think the tables answer the precedence of padding, escaping and encoding that we had when discussing escape schemes. On parsing it should be remove padding, remove escape characters, apply encoding. On unparsing it is the reverse but the tables look the same. I think the difficulty is that escape scheme is used for identification and extraction but also during conversion. I don't think the core properties (inputvaluecalc, etc) apply to sequence, choice or any. xxxPadKind is checked before xxxPadCharacter, xxpadxxx Calendar-binary. binaryCalendarFormatRef is only used when binCalRep = packed or bcd Alan Powell MP 211, IBM UK Labs, Hursley, Winchester, SO21 2JN, England Notes Id: Alan Powell/UK/IBM email: alan_powell@uk.ibm.com Tel: +44 (0)1962 815073 Fax: +44 (0)1962 816898 From: Steve Hanson/UK/IBM@IBMGB To: dfdl-wg@ogf.org Date: 08/05/2009 17:24 Subject: [DFDL-WG] DFDL: Action 027 - rework of property precedence - plus issues arising I've created a separate property precedence for each schema object that can carry non-scoping DFDL properties (attached for review). The following issues were noted: 1) Missing property dfdl:textBooleanJustification - similar properties exist for string, number and calendar types. 2) What is the rule when the same DFDL properties occur on a xs:simpleType and a xs:element that uses that type? Does this work a) like element/group references (ie, properties combined with element winning) or b) like complex element and its sequence (ie, element and simpleType are considered separate objects)? I don't think section 10 covers this case. 3) Should we allow the DFDL nil & default control properties on a simple type? xs:nillable and xs:default are element only attributes in xsd. Spec currently allows this. 4) Should we allow DFDL occurs properties on global elements? Whether something repeats is a particle thing. Spec currently allows this. (IBM's WTX and MRM don't allow this). 5) Missing work item to get BiDi properties into shape and incorporated into spec. Should these be grouped, like escape scheme, calendar scheme, etc? Do they apply to calendar and number types? 6) Should dfdl:integerBooleanXXXRep be renamed dfdl:binaryBooleanXXXRep ? 7) We might want to reconsider the name of the new flag dfdl:initiated - it could be read that the xs:sequence itself is initiated rather than its children. 8) Should dfdl:initiated also apply to xs:choice? 9) Draft 33 property precedence had dfdl:outputLengthCalc - but that is not in the spec anywhere else? Regards Steve Hanson Programming Model Architect WebSphere Message Brokers Hursley, UK Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 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 [attachment "Property Precedence 034.doc" deleted by Alan Powell/UK/IBM] -- dfdl-wg mailing list dfdl-wg@ogf.org http://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
My markup on this attached - mostly using comment balloons on the side. Mike Beckerle | OGF DFDL WG Co-Chair | CTO | Oco, Inc. Tel: 781-810-2125 | 100 Fifth Ave., 4th Floor, Waltham MA 02451 | <mailto:mbeckerle.dfdl@gmail.com> mbeckerle.dfdl@gmail.com _____ From: dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org] On Behalf Of Steve Hanson Sent: Friday, May 08, 2009 12:23 PM To: dfdl-wg@ogf.org Subject: [DFDL-WG] DFDL: Action 027 - rework of property precedence - plusissues arising I've created a separate property precedence for each schema object that can carry non-scoping DFDL properties (attached for review). The following issues were noted: 1) Missing property dfdl:textBooleanJustification - similar properties exist for string, number and calendar types. 2) What is the rule when the same DFDL properties occur on a xs:simpleType and a xs:element that uses that type? Does this work a) like element/group references (ie, properties combined with element winning) or b) like complex element and its sequence (ie, element and simpleType are considered separate objects)? I don't think section 10 covers this case. 3) Should we allow the DFDL nil & default control properties on a simple type? xs:nillable and xs:default are element only attributes in xsd. Spec currently allows this. 4) Should we allow DFDL occurs properties on global elements? Whether something repeats is a particle thing. Spec currently allows this. (IBM's WTX and MRM don't allow this). 5) Missing work item to get BiDi properties into shape and incorporated into spec. Should these be grouped, like escape scheme, calendar scheme, etc? Do they apply to calendar and number types? 6) Should dfdl:integerBooleanXXXRep be renamed dfdl:binaryBooleanXXXRep ? 7) We might want to reconsider the name of the new flag dfdl:initiated - it could be read that the xs:sequence itself is initiated rather than its children. 8) Should dfdl:initiated also apply to xs:choice? 9) Draft 33 property precedence had dfdl:outputLengthCalc - but that is not in the spec anywhere else? Regards Steve Hanson Programming Model Architect WebSphere Message Brokers Hursley, UK Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 _____ 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
participants (3)
-
Alan Powell -
Mike Beckerle -
Steve Hanson