[DFDL-WG] Action 242: valueLength of complexType - contentLength and valueLength functions
Steve Hanson
smh at uk.ibm.com
Mon Aug 1 06:40:41 EDT 2016
Mike
That all looks sensible to me. Let's discuss on call tomorrow.
Regards
Steve Hanson
IBM Integration Bus, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
From: Mike Beckerle <mbeckerle.dfdl at gmail.com>
To: "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
Date: 19/07/2016 19:04
Subject: [DFDL-WG] Action 242: valueLength of complexType -
contentLength and valueLength functions
Sent by: "dfdl-wg" <dfdl-wg-bounces at ogf.org>
(There are a few separate email threads related to Action 242. They have
different subject lines, but all mention Action 242.)
Experience with the Daffodil unparser implementation and
dfdl:outputValueCalc has led us to a number of conclusions:
1) we need the concept of valueLength of a complexType which excludes the
ElementUnused region, so that contentLength of a complexType can include
the ElementUnused region.
The example that motivates this is from PCAP where there are length fields
that aren't the exact length while unparsing but contain other factors:
<element name="len" type="xs:int" dfdl:outputValueCalc="{
fn:max(dfdl:valueLength(../ctElem, 'bytes'), 60) }" .../>
...
<element name="ctElem" dfdl:length="{ ../len }" .../>
In the above, we have a complex type element that has a minimum length of
60. So when unparsing if the actual length of the choice/sequence that is
the model group of the ctElem is of length less than 60, we need to fill
out the ElementUnused region of the DFDL grammar so as to achieve the min
length of 60 bytes.
If the dfdl:outputValueCalc of the len element was to call
dfdl:contentLength, then we would have a circularity.
Erratum 5.18 clarifies that length expressions are evaluated when
unparsing to produce the target length that is used for pad/fill.
This concept must be extended to complex types so that it also addresses
the ElementUnused region that can follow the model group of a complex
type.
To clarify all this I suggest the DFDL data grammar must be changed as
follows:
ComplexNormalRep = LeftFraming PrefixLength ComplexContent RightFraming #
Unchanged. Just here for context
ComplexContent = ComplexValue ElementUnused
ComplexValue = Sequence | Choice
The above change basically moves ELementUnused out of the ComplexNormalRep
production into a separate ComplexContent production, and distinguishes
ComplexValue from ComplexContent.
With the above grammar rule changes, I believe the spec as modified for
Erratum 5.18 will be correct. (Everyplace where lengthKind explicit is
lumped in with prefixed etc must be broken out, as it is a different case.
)
2) Spec says escapeCharacter, escapeBlockStart, and excapeBlockEnd
contribute to the content length of an element. (Note:
escapeEscapeCharacter is missing this stipulation and should be made
consistent.)
However, I believe this is incorrect. These all contribute to the *value*
length, that is to say, they appear within the "SimpleValue |
NilLogicalValue" region of the grammar.
3) Definition of dfdl:valueLength must be changed to specify that it
returns the length of the ComplexValue region for complex types, and
excludes any filling of the ElementUnused region.
The definition of dfdl:contentLength is acceptable as is.
However, both require clarification as to when "characters" and "bytes"
are allowed relative to the lengthUnits of the element that is the
argument.
(This length units topic is a separate matter and will be a separate
message.)
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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20160801/9d82cc34/attachment.html>
More information about the dfdl-wg
mailing list