Mike I'd like to state what we said were the use cases yesterday. There were three. . Use case 1 Element "val" is fixed length, length known at design time and provided by dfdl:length="x" on input and output. On output, the infoset data for "val" is padded to the length. Use case 2 Element "val" is fixed length, length known at runtime and provided by dfdl:length="{..\len}" on input and output. On output the infoset provides the value for element "len". On output, the infoset data for "val" is padded to the length according to the rules for dfdl:lengthKind='explicit'/'implicit'. Use case 3 Element "val" is really variable length, length only known once the data is serialised, and provided by dfdl:length="..\len" on input. On output the value of element "len" is set only once the length of "val" is known. On output, the infoset data for "val" is not padded to the length. You've added a variation to use case 3 in your example, where there is a need to add some padding. Let's call it use case 4. Alan and I have explored an alternative, where dfdl:length is always used for all use cases. The difference for use case 3 & 4 is that the value of element "len" is only set during the processing of "val". Instead of using a flag, with accompanying output length property, to signal case 3 & 4, we use an extra parameter on dfdl:length() that says whether to use padding or not when dfdl:lengthKind="explicit"/"implicit". Note that any escape scheme must and will be taken into account (to answer your question). For use case 3 when no padding is needed you example simplifies to the following. When "len" is encountered, there is an outputValueCalc that references "val" so the unparser defers the setting of the value of "len". When it gets to "val", it knows it must work out its unpadded length, and set that in "len", before doing any length related processing for "val". <sequence> <element name="len" type="int" dfdl:outputValueCalc= "{ dfdl:length(../val, false) !-- false => no pad }" /> ... many elements in between .... <element name="val" type="string" dfdl:encoding="utf-8" dfdl:lengthKind="explicit" dfdl:lengthUnits="bytes" dfdl:length="{ ../len }" dfdl:textTrimKind="padChar" dfdl:textStringJustification="left" dfdl:textPadCharacter="%#r0;" /> </sequence> For use case 4 when some padding might be needed you example simplifies to the following. When the unparser starts to process "val", it works out the unpadded length, uses it in the expression and generates the value for "len". When it does the length processing for "val" it pads to the value of "len". <sequence> <element name="len" type="int" dfdl:outputValueCalc= "{ fn:ceiling(dfdl:length(../val, false) div 4) * 4 }" /> ... many elements in between .... <element name="val" type="string" dfdl:encoding="utf-8" dfdl:lengthKind="explicit" dfdl:lengthUnits="bytes" dfdl:length="{ ../len }" dfdl:textTrimKind="padChar" dfdl:textStringJustification="left" dfdl:textPadCharacter="%#r0;" /> </sequence> A variation on use case 4 is when we need to pad to a minimum length. <sequence> <element name="len" type="int" dfdl:outputValueCalc= "{ fn:min(dfdl:length(../val, false), 20) }" /> ... many elements in between .... <element name="val" type="string" dfdl:encoding="utf-8" dfdl:lengthKind="explicit" dfdl:lengthUnits="bytes" dfdl:length="{ ../len }" dfdl:textTrimKind="padChar" dfdl:textStringJustification="left" dfdl:textPadCharacter="%#r0;" /> </sequence> You might be tempted to ask why the minimum is explicitly added. It's because, as currently spec'd, xs:minLength facet (and dfdl:outputMinLength for non-strings) are not used when dfdl:lengthKind="explicit". We could change this but it does make the padding rules more complicated. We opted for leaving the padding rules simpler. Yesterday we also dsicussed whether implict/explicit needed to change. With the above scheme we think a change is not necessary. Regards Steve Hanson Programming Model Architect WebSphere Message Brokers Hursley, UK Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 "Mike Beckerle" <mbeckerle.dfdl@gmail.com> Sent by: dfdl-wg-bounces@ogf.org 09/06/2009 04:30 Please respond to mbeckerle.dfdl@gmail.com To <dfdl-wg@ogf.org> cc Subject [DFDL-WG] outputValueCalc and unparse example I did not get as far as I wanted to on this issue. I would like to discuss this example: <sequence> <element name="len" type="int" dfdl:fillByte="%#r0;" dfdl:outputValueCalc= "{ dfdl:representation-output-length(../val) }" /> ... many elements in between .... <element name="val" type="string" dfdl:encoding="utf-8" dfdl:lengthKind="explicit" dfdl:lengthUnits="bytes" dfdl:useLengthForOutput="false" dfdl:length="{ ../len }" dfdl:outputLength="{ fix:ceiling( dfdl:representation-inherent-length(.) div 4 ) * 4 }" dfdl:textTrimKind="padChar" dfdl:textStringJustification="left" dfdl:textPadCharacter="%#r0;" /> </sequence> You will notice I added a dfdl:outputLength property, and a dfdl:representation-output-length() function and dfdl:representation-inherent-length(). I am accepting candidates for better names for these properties and functions. We need to distinguish these 3 concepts: 1) inherent length – of the infoset item without reference to any facets, and with out respect to escape sequences, padding or truncation. (TBD: think about escape sequences? Is this right) 2) output target length – the length of the box we’re filling in with the data value representation. The box can be bigger or smaller than the inherent length, which implies use of padding/filling, or truncation. 3) input length – length of the box we’re getting when parsing. The inherent length of the value after parsing can be smaller than the length of the box due to removal of escape characters, and the trimming of padding. -- 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