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