June 2013 - dfdl-wg - lists.ogf.org

terminate by next field's initiator aka lengthKind="endAtStartOfNext" or something like that
by Mike Beckerle 04 Jun '13

04 Jun '13

I know we omitted this from DFDL v1.0 (I am quite sure I advocated that position), and we're too late to add it back now, but while theoretically possible I had never seen this before, but now I have seen it and I'm wondering if it is more common than I originally thought. The situation is this. I have an element. It wants to be delimited in that it has an escape scheme, and it is delimited by something in the common-sense of the word, but the terminator is actually what one thinks of as the initiator of the next element. It comes up in Internet Message Format headers as one example: Reply-To: joe(a)foo.com Reply-To: <joe(a)foo.com> Reply-To: joe smith<joe(a)foo.com> Reply-To: "joe <Mr. XML> smith"<joe(a)foo.com> Reply-To: <> In the 3rd and fourth case, there is no terminator, just the required < which begins the next field. Modeling this whole reply-to construct requires a choice of several different elements which model the different formats. For example I see no way to model a format which accepts either line one or line 2 of the above without using a choice. That said, my real concern is with lines 3 and 4. The natural model for lines 3 and 4 (and perhaps 5) seems like it should be a display-name field followed by an email address field. The "<" really does not want to be used in some situations as the terminator of the prior field and in others as the initiator of the next field. That affects reuse of the validation regex's, etc. Right now the only way to model this is for the display name field to use a regex which re-invents the escape-scheme-like behavior of the optional quotation mark surround, and uses regex lookahead to sense the "<" when it appears unescaped, without consuming it. That's not too bad really, but I am curious what others have seen out there in the world of data that also has this idiom where a string is delimited by a unique structure at the beginning of the next element. Do we have collective knowledge of several more such formats, or have we all just seen this same IMF header example as the motivation. -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com

2 1

OGF DFDL WG Call Agenda 2013-06-04
by Steve Hanson 03 Jun '13

03 Jun '13

Please find agenda for call on Redmine at http://redmine.ogf.org/dmsf_files/13082?download= Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

lengthUnits 'bits' and binaryNumberRep
by Steve Hanson 03 Jun '13

03 Jun '13

For discussion on next WG call: The description of the dfdl:lengthUnits property for enum 'bits' says (after errata 2.90): 'bits' may only be used for xs:boolean, xs:byte, xs:short, xs:int, xs:long, xs:unsignedByte, xs:unsignedShort, xs:unsignedInt, and xs:unsignedLong simple types with representation 'binary'. This is permitting binary numbers with dfdl:binaryNumberRep 'packed', 'bcd' and 'ibm4690Packed' to have dfdl:lengthUnits 'bits'. That could make sense, as one could have an odd number of nibbles packed into the minimum space possible - eg a BCD range 000-999 could occupy 12 bits. However, the words that have been added for errata 2.90 (allowing signed number types to have lengthUnits 'bits') to both the description of dfdl:lengthUnits and section 12.3.7.2 have assumed that only binaryNumberRep 'binary' is allowed. I tested IBM DFDL with 12-bit 'packed' and 'bcd' reps packed back-to-back with bit alignment and it parsed them ok, but gave an error when serializing, saying that binaryNumberRep must be 'binary'. Clearly incorrect because of the inconsistency, but what is the intent of the spec here? Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-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

1 0

0 equals ""?
by Garriss Jr., James P. 03 Jun '13

03 Jun '13

When are these not functionally equal? <dfdl:discriminator>{ dfdl:valueLength(../Empty, "bytes") eq 0 }</dfdl:discriminator> <dfdl:discriminator>{ ../Empty eq "" }</dfdl:discriminator> TIA

2 1