Thanks Steve, your input is very appreciated. We will check internally how to proceed.

On 03 Mar 2016, at 18:05 , Steve Hanson <smh@uk.ibm.com> wrote:

Michele, Rui

1) This is a deviation from the DFDL 1.0 specification and should be corrected. The context for the evaluation of a DFDL discriminator (or assert or indeed any DFDL expression) is the object on which the annotation occurs (if expression is on an element) or the nearest parent element (if expression is on a sequence or choice).

2) Looking at the kinds of tests you are doing with dmx:assertExpression, I think you could use dfdl:assert with a recoverableException.

Regards

Steve Hanson IBM Integration Bus <http://www-03.ibm.com/software/products/en/ibm-integration-bus>, Hursley, UK Architect, IBM DFDL <http://www.ibm.com/developerworks/library/se-dfdl/index.html> Co-Chair, OGF DFDL Working Group <http://www.ogf.org/dfdl/> smh@uk.ibm.com <mailto:smh@uk.ibm.com> tel:+44-1962-815848 mob:+44-7717-378890

From: Michele Zundo <michele.zundo@esa.int> To: Steve Hanson/UK/IBM@IBMGB, Mike Beckerle <mbeckerle@tresys.com>, Montserrat Piñol <mpinol@eopp.esa.int>, Maurizio De Bartolomei <mdebartolomei@eopp.esa.int>, Rui Mestre <rui.mestre@deimos.com.pt>, DFDL-WG <dfdl-wg@ogf.org> Date: 03/03/2016 16:05 Subject: [DFDL4S]: Results of OGF DFDL WG Call Agenda 2016-02-16

Dear Steve/Mike,

here few considerations regarding the 2 points in the MoM:

1) Regarding the evaluation of the XPath expressions in the dfdl:discriminator tests:

From: "Rui Mestre (DME)" <rui.mestre@deimos.com.pt <mailto:rui.mestre@deimos.com.pt>>

Our implementation of the DFDL parser is based on a slightly different interpretation of the way the paths are applied. Our approach is based on the fact that the discriminator expression is not being evaluated at the level of the element containing the discriminator but instead at the level of the type containing such element.

In the example at hand the type TypeMasterChId is defined with an element "Transfer_Frame_Version" followed by a "choice" among several alternative elements Spacecraft_Id_V*. So the decision of which "choice" branch to choose is done while "located" at the root level of TypeMasterChId. While parsing the sub-components of TypeMasterChId the several branches of the "choice" construct are evaluated (in order) and the first one evaluating to "true" is the one selected. Hence the relative path is written in reference to the top level of the type. Therefore in such cases the paths start with "./" instead of "../".

2) dfdl:assert vs dmx:assertExpression

The question from Steve: “Also you said that you saw no need to implement DFDL assert - so what are the dmx:assertExpression attributes doing? “

(Maurizio De Bartolomei) : as far as I understood, the DFDL assert shall be used to check that data is well formed (i.e. the data is compliant to a given structure and can be parsed) and not for data validation (i.e. inspecting the content of a given element and comparing against an expected value). The dmx:assertExpression does not check that the data is well formed but only checks the value of a given item against an expected value, if the value is different a message is returned. This can be improved by either changing the expression name (i.e. dmx:checkExpression) or investigate if DFDL provides already suitable expressions for content validation without loosing the compactness and clarity of dmx:assertExpression).

From: "Rui Mestre (DME)" <rui.mestre@deimos.com.pt <mailto:rui.mestre@deimos.com.pt>>

Regarding the use of dmx:assertExpression (as opposed to dfdl:assert) we fully agree with Maurizio's answer above About his statement "(...)or investigate if DFDL provides already suitable expressions for content validation without loosing the compactness and clarity of dmx:assertExpression" we had in fact identified an alternative: a possibility is to use XML Schema facets to capture the assert expression by a restriction to the data type. However that approach does not cover the semantics currently available in our "custom" operators (in,inrange, et al.). So until the DFDL standard is updated to contain the corresponding semantics it would not be possible to completely replace the dmx:assertExpression with a standard DFDL (or in this case XML) construct.

*******

From: Steve Hanson <smh@uk.ibm.com <mailto:smh@uk.ibm.com>> Subject: Re: OGF DFDL WG Call Agenda 2016-02-16 Date: 1 March 2016 at 19:12:13 GMT+1 To: Michele Zundo <michele.zundo@esa.int <mailto:michele.zundo@esa.int>> Cc: DFDL-WG <dfdl-wg@ogf.org <mailto:dfdl-wg@ogf.org>>, Mike Beckerle <mbeckerle@tresys.com <mailto:mbeckerle@tresys.com>>

Hi Michele

Here is an example of where I do not think the relative path is correct. The discriminator expression should be {../Transfer_Frame_Version in [0]}. In infoset terms, Spacecraft_Id_V1 is a sibling of Transfer_Frame_Version.

Also you said that you saw no need to implement DFDL assert - so what are the dmx:assertExpression attributes doing?

<xs:complexType name="TypeMasterChId"> <xs:sequence> <xs:element name="Transfer_Frame_Version" type="xs:int" dfdl:lengthKind="explicit" dfdl:lengthUnits="bits" dfdl:length="2" dmx:representation="Integer16" dmx:assertExpression="../Transfer_Frame_Version eq 1" dmx:assertMessage="Invalid TF version detected." dmx:assertPropagate="true"/> <xs:choice> <xs:element name="Spacecraft_Id_V1" type="xs:int" dfdl:lengthKind="explicit" dfdl:lengthUnits="bits" dfdl:length="10" dmx:representation="Integer32" > <xs:annotation> <xs:appinfo source="http://www.ogf.org/dfdl/dfdl-1.0/ <http://www.ogf.org/dfdl/dfdl-1.0/>"> <dfdl:discriminator test="{./Transfer_Frame_Version in [0]}" /> </xs:appinfo> </xs:annotation> </xs:element> <xs:element name="Spacecraft_Id_V2" type="xs:int" dfdl:lengthKind="explicit" dfdl:lengthUnits="bits" dfdl:length="8" dmx:representation="UInteger8" dmx:assertExpression="../Spacecraft_Id_V2 in [82, 83, 84]" dmx:assertMessage="Invalid Spacecraft ID detected."> <xs:annotation> <xs:appinfo source="http://www.ogf.org/dfdl/dfdl-1.0/ <http://www.ogf.org/dfdl/dfdl-1.0/>"> <dfdl:discriminator test="{true}" /> </xs:appinfo> </xs:annotation> </xs:element> </xs:choice> </xs:sequence> </xs:complexType>

Regards

Steve Hanson IBM Integration Bus <http://www-03.ibm.com/software/products/en/ibm-integration-bus>, Hursley, UK Architect, IBM DFDL <http://www.ibm.com/developerworks/library/se-dfdl/index.html> Co-Chair, OGF DFDL Working Group <http://www.ogf.org/dfdl/> smh@uk.ibm.com <mailto:smh@uk.ibm.com> tel:+44-1962-815848 <tel:+44-1962-815848> mob:+44-7717-378890

-- ----------------------------------------- Michele Zundo

Head of Ground System Definition and Verification Office EOP-PEP European Space Agency, ESTEC e-mail: michele.zundo@esa.int <mailto:michele.zundo@esa.int>

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

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

----------------------------------------- Michele Zundo Head of Ground System Definition and Verification Office EOP-PEP European Space Agency, ESTEC e-mail: michele.zundo@esa.int This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email.