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, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
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>
   
     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>

         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>
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>
Cc: DFDL-WG <dfdl-wg@ogf.org>, Mike Beckerle <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/">
                                                       <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/">
                                                       <dfdl:discriminator test="{true}" />
                                               </xs:appinfo>
                                       </xs:annotation>
                               </xs:element>
                       </xs:choice>
               </xs:sequence>
       </xs:complexType>



Regards

Steve Hanson
IBM Integration Bus, Hursley, UK
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
smh@uk.ibm.com
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








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