- dfdl-wg - lists.ogf.org

newbie question
by Bing Lu 28 Mar '14

28 Mar '14

what's the best dfdl approache to describe a variable length alpha numeric field? should i use simpletype restriction pattern, or use dfdl:assert testPattern? thanks in advance

2 1

alignment questions
by Mike Beckerle 26 Mar '14

26 Mar '14

Are leadingSkip always byte aligned, or are they N * 8 bits added on. Similarly trailingSkip E.g., <element name="x" type="xs:int" dfdl:lengthKind="explicit" dfdl:length="1" dfdl:lengthUnits="bits" dfdl:trailingSkip="10" dfdl:alignmentUnits="bytes" dfdl:alignment="1"/> So, after this element am I at bit 81 or bit 88? In other words, does the trailingSkip region get aligned per size of alignment unit, or does alignment really only happen at the beginning of an element. 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<http://www.ogf.org/About/abt_policies.php>

2 1

OGF DFDL WG Call Minutes 2014-03-25
by Steve Hanson 26 Mar '14

26 Mar '14

Please find minutes from the above call at http://redmine.ogf.org/dmsf_files/13220?download= Next call is Fri 11th April @ 3pm UK. Regards Steve Hanson Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Rescheduled: DFDL Working Group Call (11 Apr 15:00 GDT in DE3S09)
by Steve Hanson 26 Mar '14

26 Mar '14

Rescheduled: DFDL Working Group Call 11/04/2014 - (Repeats) Location: DE3S09 Steve Hanson has rescheduled this meeting. You have not yet responded. Repeats This entry repeats Required: jcranford(a)mitre.org, mbeckerle(a)tresys.com, Suman Kalia/Toronto/IBM@IBMCA, Tim Kimber/UK/IBM@IBMGB Optional: Alex Wood1/UK/IBM@IBMGB, Andrew Edwards/UK/IBM@IBMGB, dfdl-wg(a)ogf.org, jonathan.w.cranford(a)gmail.com, Mark Frost/UK/IBM, mbeckerle.dfdl(a)gmail.com, Stephanie Fetzer/Charlotte/IBM@IBMUS OGF DFDL WG weekly call dial-in details. Passcode for Participants: 5381214 Canada Toll-Free 888-426-6840 China Toll-Free 10-800-711-1071 CHINA NETCOM GROUP USERS China Toll-Free 10-800-110-0996 CHINA TELECOM SOUTH USERS France Toll-Free 0800-94-0558 Germany Toll-Free 0800-000-1018 India Toll-Free 000-800-100-1176 Ireland Toll-Free 1-800-943-427 Israel Toll-Free 1-809-417-783 United Kingdom Caller Paid 0-20-30596451 United Kingdom Toll-Free 0800-368-0638 USA Caller Paid 215-861-6239 USA Toll-Free 888-426-6840 Other international numbers available - e-mail smh(a)uk.ibm.com. OGF DFDL Home: http://www.ogf.org/dfdl Redmine DFDL: http://redmine.ogf.org/projects/dfdl-wg

1 0

Cancelled: DFDL Working Group Call
by Steve Hanson 26 Mar '14

26 Mar '14

Cancelled: DFDL Working Group Call 01/04/2014 - (Repeats) Location: DE3S09 Steve Hanson has cancelled this meeting. Your calendar will be updated to reflect this change. Repeats This entry repeats Required: jcranford(a)mitre.org, mbeckerle(a)tresys.com, Suman Kalia/Toronto/IBM@IBMCA, Tim Kimber/UK/IBM@IBMGB Optional: Alex Wood1/UK/IBM@IBMGB, Andrew Edwards/UK/IBM@IBMGB, dfdl-wg(a)ogf.org, jonathan.w.cranford(a)gmail.com, Mark Frost/UK/IBM, mbeckerle.dfdl(a)gmail.com, Stephanie Fetzer/Charlotte/IBM@IBMUS

1 0

lengthUnits bits not allowed for complex type - Unnecessary restriction on length units?
by Mike Beckerle 26 Mar '14

26 Mar '14

In section 12.3.7.3 we have this sentence: "The dfdl:lengthUnits may be 'bytes' or 'characters' and it is a schema definition error otherwise. " Does anyone recall why we have this? I have data formats which are bit oriented and there are complex types which would naturally not be a multiple of 8 bytes long, e.g., 1 bit field, 3 bit field, 10 bit field, 6 bit field = 20 bits. I can't think of any reason for this restriction other than to explain how fillByte is used to fill in unused bits. But I think we can say that any unused bits are filled in with bits from the fillByte, and we don't have to be specific about which bits from the fillByte. 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<http://www.ogf.org/About/abt_policies.php>

2 2

Initiator with leading variable text
by John Coutinh 25 Mar '14

25 Mar '14

2 1

Re: [DFDL-WG] Action 242 - valueLength and contentLength function wording
by Steve Hanson 24 Mar '14

24 Mar '14

Note errata 3.9, my bolding: "3.9. Section 12.3.5, 7.3.1, 7.3.2. The spec originally allows lengthKind ‘pattern’ to be used when the representation of the current element, or of a child element, is binary, but imposes restrictions on the encoding that can be in force. Clarify that the encoding property must be defined for the element (else schema definition error), and that a decoding processing error is possible if the match of the regex encounters data that does not decode in that encoding, dependent on the setting of encodingErrorPolicy. Remove section 12.3.5.1. Same clarifications needed for testKind ”pattern” property for asserts and discriminators. For consistency, the restriction that a complex element of specified length and lengthUnits ‘characters’ must have children that are all text and that have the same encoding as the complex element, is dropped." That's the restriction that I was referring to in my comment below. I can see why it was dropped - basically the parser now just tries to decode n characters using the complex element's encoding (and encodingErrorPolicy). We could apply the same principle for dfdl:valueLength & dfdl:contentLength - you build the stream from the bottom up, and then decode it using the complex element's encoding (and encodingErrorPolicy ?) to get the length in characters. Note that's how unparsing for lengthKind 'prefixed' with lengthUnits 'characters' would work as well - the spec just says "For a complex element, the length is that of the ComplexContent region" which is not sufficient (12.3.4). Similar deal for lengthKind 'explicit' - in order to know the size in chars of ElementUnused the unparser needs to know the size in chars of the data first (12.3.7.3). (Of course, for a fixed width encoding, you don't need to decode, you can just do the maths, but for the general case you need to decode. Also just doing the maths does not take encodingErrorPolicy into account). Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com>, Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org>, dfdl-wg-bounces(a)ogf.org Date: 24/03/2014 12:55 Subject: Re: [DFDL-WG] Action 242 - valueLength and contentLength function wording Mike 23.5.3.1. Value length is only a function of the dfdl:encoding property if the element has a text representation. Not sure this needs to be (re)stated here. 23.5.3.1. "The value length is computed from the DFDL infoset value, ignoring the dfdl:length or dfdl:textOutputMinLength property. Other DFDL properties which affect the length of a text or binary representation are respected, it is only an explicit length which is ignored." Last sentence is too imprecise - should be phrased in terms of the grammar. 23.5.3.1. "If the second argument is 'characters' then the element must have text representation and it is a schema definition error otherwise". Yes but only for a simple type, so should be qualified. 23.5.3.1. "If the second argument, giving the length units, is 'characters', then recursively, this complex type element must have text representation throughout all its contained elements and framing, all of which must also use a uniform character set encoding." I can't see that restriction elsewhere in the spec when it talks about length of ComplexContent and lengthUnits 'characters' - I was expecting it to be in section 12.3.4 or 12.3.7.3 which face the same issue - but it isn't. Did we decide not to have this restriction? Without such a restriction, how does the unparser come up with a meaningful length (unless it re-parses)? (Tim - what does IBM DFDL do here?) What about delimiters and padding of children that use %#r entities? 23.5.3.2. The points in 23.5.3.1 about escape characters, length as a function of encoding, and bottom up for complex elements, apply equally to 23.5.3.2. It might be easier just to say in 23.5.3.2 that dfdl:contentLength for complex elements is same as dfdl:valueLength, and for simple elements differs only by the additional inclusion of LeftPadding and RightPadOrFill regions. Also noted in passing: Specified length - An item has specified length when dfdl:lengthKind is "implicit", "explicit", or "prefixed". should be Specified length - An element has specified length when dfdl:lengthKind is "implicit" (simple type only), "explicit", or "prefixed". Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org>, Date: 20/03/2014 17:21 Subject: [DFDL-WG] Action 242 - valueLength and contentLength function wording Sent by: dfdl-wg-bounces(a)ogf.org See attached doc which is proposed revisions to section 23.5.3 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(a)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

1 0

Action 242 - valueLength and contentLength function wording
by Mike Beckerle 24 Mar '14

24 Mar '14

See attached doc which is proposed revisions to section 23.5.3 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<http://www.ogf.org/About/abt_policies.php>

3 2

OGF DFDL WG Call 2014-03-18 - cancelled
by Steve Hanson 18 Mar '14

18 Mar '14

Sorry have to cancel the call, but Mike and Tim are unable to make it. Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0