I think automatic padding to the specified or minimum length is better than the alternative ( throwing a processing error ). Arguably, throwing a processing error is more flexible because it offers the client an option to reject too-short data. But a dfdl:assert could do the same in the ( probably rare ) cases where that is the requirement.

regards,

Tim Kimber, Common Transformation Team,
Hursley, UK
Internet:  kimbert@uk.ibm.com
Tel. 01962-816742  
Internal tel. 246742




From:        Steve Hanson/UK/IBM@IBMGB
To:        dfdl-wg@ogf.org
Date:        20/05/2012 07:22
Subject:        [DFDL-WG] Unparsing hexBinary data
Sent by:        dfdl-wg-bounces@ogf.org

---

When unparsing xs:string data of specified length, then if the data is short then it is padded to the specified or minimum length (depends on dfdl:lengthKind). Whether to do this padding or not is controlled by the dfdl:textPadKind property,

However we don't offer the same flexibility for xs:hexBinary.  There's no controlling property, so we always output exactly what was in the infoset, and if specified length and the data is short it is a processing error. In the absence of a property to control whether to pad, would we better off always padding (using dfdl:fillByte) to specified or minimum length?

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
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--
 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