[DFDL-WG] Need dfdl:inputValueCalc and dfdl:outputValueCalc on same element
Steve Hanson
smh at uk.ibm.com
Tue Aug 2 12:51:40 EDT 2016
"Ultimately w.r.t. other needs that arise from IVC/OVC and unparsing, what
I'd like to do is park this issue. As we flesh out more issues of IVC and
OVC, we'll accumulate an experience document, a set of implementation
techniques etc. Then we'll see what set of concrete proposals come out of
this that need to be fixes to DFDL v1.0 as opposed to improvements for
DFDL 2.0. "
WG agreed this was the best way forward.
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: Steve Hanson/UK/IBM at IBMGB
Cc: "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
Date: 26/07/2016 15:08
Subject: Re: [DFDL-WG] Need dfdl:inputValueCalc and
dfdl:outputValueCalc on same element
So, the workaround of just repeating the expression is fine.
Using a variable, well .... this whole structure of mine appears inside an
array in the PCAP format. So using a variable requires
newVariableInstance:
<dfdl:defineVariable name="PL" type="xs:int"/>
...
<sequence>
<annotation><appinfo ...>
<dfdl:newVariableInstance ref="ex:PL">{
../length - 20
}</dfdl:newVariableInstance>
</appinfo></annotation>
<element name="length" type="xs:int"
dfdl:outputValueCalc="{ dfdl:contentLength(../payload) + 20 }">
<sequence><annotation><appinfo ...>
<dfdl:setVariable ref="ex:PL">{ ../length - 20 }</dfdl:setVariable>
</appinfo></annotation></sequence>
<element name="payloadLength" type="xs:int"
dfdl:inputValueCalc="{ $ex:PL }" />
<element name="payload" dfdl:length="{ $ex:PL }">
<complexType>.....</complexType>
</element>
</sequence> <!-- ends the newVariableInstance for PL -->
As you point out the payloadLength element is really just there to exhibit
this length as a feature of the infoset. The variable serves to carry the
expression so that it needn't be repeated.
Compare the above to my re-formulated proposed version allowing both IVC
and OVC on the same element:
<element name="length" type="xs:int"
dfdl:outputValueCalc="{ dfdl:contentLength(../payload) + 20 }">
<element name="payloadLength" type="xs:int"
dfdl:inputValueCalc="{ ../length - 20 }"
dfdl:outputValueCalc="{ ../length - 20 }"/>
<element name="payload" dfdl:length="{ ../payloadLength }">
<complexType>.....</complexType>
</element>
I'm still having to repeat the ../length - 20 expression twice, and the
only way I can avoid that is by introducing a newVariableInstance to
factor out the common subexpression which is not worth it in this case.
(Or I suppose a new dfdl:valueCalc=... property which means to compute on
both parse and unparse.) Whether the computed element appears in the
infoset or not depends on whether it is hidden or not.
The above also solves the array-variables problem (separate problem -
separate email thread to discuss this) as if there is an array of these
things, the path to a specific instance of payloadLength within that array
is effectively an array variable. (and would be hidden if you don't want
the array variable in the infoset. )
Honestly, had we considered IVC/OVC both on the same hidden element, I
might have advocated to have this in DFDL as a way to avoid having
variables and especially newVariableInstance altogether.
The only drawback is that one cannot use them without a complex type being
involved, which is an awkwardness we inherit from XML Schema which results
in many elements named "value" that serve to carry a simple type within a
complex type enclosure. I.e.,
<mySimpleElement><value>foo</value></mySimpleElement>. This has been
discussed before, and we decided not to fix it for DFDL v1.0. (We will be
experimenting with allowing a hidden group ref from a simple type
definition as a way to fix this. )
Now, given all that discussion (and digression) ...
I do have a workaround in this case: as you suggested, I can just repeat
the expression:
<element name="length" type="xs:int"
dfdl:outputValueCalc="{ dfdl:contentLength(../payload) + 20 }">
<element name="payloadLength" type="xs:int"
dfdl:inputValueCalc="{ ../length - 20 }" />
<element name="payload" dfdl:length="{ ../length - 20 }">
<complexType>.....</complexType>
</element>
So that's what I will do for now.
Ultimately w.r.t. other needs that arise from IVC/OVC and unparsing, what
I'd like to do is park this issue. As we flesh out more issues of IVC and
OVC, we'll accumulate an experience document, a set of implementation
techniques etc. Then we'll see what set of concrete proposals come out of
this that need to be fixes to DFDL v1.0 as opposed to improvements for
DFDL 2.0.
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
On Tue, Jul 26, 2016 at 3:50 AM, Steve Hanson <smh at uk.ibm.com> wrote:
If I understand the example correctly, you have added 'payloadLength' to
the infoset as a convenience to the user, but at the same time you are
referencing it from the 'payload' element's dfdl:length property. Your
example could be changed to use the 'length' element instead:
<element name="length" type="xs:int"
dfdl:outputValueCalc="{ dfdl:contentLength(../payload) + 20 }">
<element name="payloadLength" type="xs:int"
dfdl:inputValueCalc="{ ../length - 20 }" />
<element name="payload" dfdl:length="{ ../length - 20 }">
<complexType>.....</complexType>
</element>
If we allow both input & output value calc on a element, it is saying that
on unparsing the element's value in the infoset is ignored, and its value
never appear in the data. So it's a place to hold a transient value, don't
we have variables for that?
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 18:49
Subject: [DFDL-WG] Need dfdl:inputValueCalc and
dfdl:outputValueCalc on same element
Sent by: "dfdl-wg" <dfdl-wg-bounces at ogf.org>
So in PCAP format we find something like this:
<element name="length" type="xs:int"
dfdl:outputValueCalc="{ dfdl:contentLength(../payload) + 20 }">
<element name="payloadLength" type="xs:int"
dfdl:inputValueCalc="{ ../length - 20 }" />
<element name="payload" dfdl:length="{ ../payloadLength }">
<complexType>.....</complexType>
</element>
To make this unparse we really need the payloadLength element to carry
both an IVC and an OVC.
Otherwise when unparsing the dfdl:length expression on the payload element
can't be meaningful. We have an erratum that states that length
expressions are always re-evaluated when unparsing, so as to produce a
target length that can be used to insert padding/fillByte.
However, the spec currently says you cannot have both IVC and OVC on the
same element.
I do not recall why we have this restriction, other than trying to
prohibit things we didn't think were necessary, but it seems in this
situation to be needed.
Comments?
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
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/20160802/50bb366b/attachment.html>
More information about the dfdl-wg
mailing list