[DFDL-WG] Action 282 (was Re: Fw: [DFDL]: First Release of DFDL4S Parser Library)

Mike Beckerle mbeckerle.dfdl at gmail.com
Wed Sep 23 11:38:21 EDT 2015


Please ignore the prior message from me. I see Steve Hanson already raised
the same issue.

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
<http://www.ogf.org/About/abt_policies.php>


On Wed, Sep 23, 2015 at 11:36 AM, Mike Beckerle <mbeckerle.dfdl at gmail.com>
wrote:

> Michele,
>
> It is possible to implement these checks using type definitions. For
> example instead of a function like
>
> <xs:element name="foo" type="xs:int">
>    <xs:annotation><xs:appinfo source="http://www.ogf.org/dfdl">
>       <dfdl:assert>{ dfdl:checkRangeInclusive(., -400, 100000)
> }</dfdl:assert>
>    </xs:appinfo></xs:annotation>
> </xs:element>
>
> one can do this:
>
>    <xs:element name="foo" type="TemperatureCelsius"/>
>
> with
>
>    <xs:simpleType name="TemperatureCelsius">
>      <xs:annotation><xs:appinfo source="http://www.ogf.org/dfdl">
>         <dfdl:assert>{ dfdl:checkConstraints(.) }</dfdl:assert>
>      </xs:appinfo></xs:annotation>
>       <xs:restriction base="xs:int">
>           <xs:minInclusive value="-400"/>
>          <xs:maxInclusive value="100000"/>
>       </xs:restriction>
>    </xs:simpleType>
>
> A library of such types could be created. This is the XSD way of doing
> this stuff, reusable with regular XML, not just DFDL.
>
> So my question then is "Is this sufficient?"
>
> This has some restrictions relative to what dfdl:checkRangeInclusive.
> Specifically, one can only check ranges specified as numeric constants
> using the facets, where the dfdl:checkRangeInclusive function takes
> arguments so they could be variables, or path expressions to compute the
> range limits from things stored in the data. While that might be useful, I
> am interested in whether you have actual need for that, or the
> type-definition approach would work.
>
>
>
>
> 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
> <http://www.ogf.org/About/abt_policies.php>
>
>
> On Tue, Sep 22, 2015 at 12:21 PM, Michele Zundo <michele.zundo at esa.int>
> wrote:
>
>> Dear Steve,
>>
>> nice to hear things are moving.
>>
>> The syntax below seems both reasonable and readable to me which is a good
>> thing.
>>
>> It addresses the belonging to decimal groups (integer only ??) I
>> understand. (xs:decimal)
>>
>> 1) It might be also useful (not in our application but in general) to see
>> if it makes sense also to define
>> for dfdl:checkValues belongings to set of “enum” like value
>>
>> e.g. if we have a type for $val defined as (ON, OFF or STANDBY) or
>> (MARRIED, SINGLE, WIDOWER)
>> can we also define a syntax that the $node belongs to it ?
>>
>> 2) for dfdl:checkRange it might make sense also to allow float numbers
>> e.g.  X between 3.1 to 9.5
>>
>>
>> Michele
>>
>>
>>
>> PS I will forward this proposal to our DFDL4S developers (in copy) to get
>> their thinking.
>>
>>
>> *From: *"Steve Hanson" <smh at uk.ibm.com>
>> *Subject: **[DFDL-WG] Action 282 (was Re: Fw: [DFDL]: First Release of
>> DFDL4S Parser Library)*
>> *Date: *22 Sep 2015 16:50:13 CEST
>> *To: *DFDL-WG <dfdl-wg at ogf.org>
>>
>>
>> To kick start this action, here is a proposal ... builds on the precedent
>> provided by dfdl:checkConstraints($node).
>> dfdl:checkValues($node, $val1, $val2, ...)Returns boolean true if the
>> specified node value matches any of the values provided by $val1 etc.
>>
>> The type of $val1 etc must be compatible with the type of $node.
>>
>> It is a schema definition error if the $node argument is a complex
>> element.
>>
>> The number of value arguments is implementation-defined.
>>
>> dfdl:checkRangeInclusive($node, $val1, $val2)
>> Returns boolean true if the specified node value is in the range given by
>> $val1 and $val2, inclusive.
>>
>> The type of $val1 and $val2 must be compatible with the type of $node,
>> and must be a derivative of xs:decimal.
>>
>> It is a schema definition error if the $node argument is a complex
>> element.
>>
>> dfdl:checkRangeExclusive($node, $val1, $val2)
>> Returns boolean true if the specified node value is in the range given by
>> $val1 and $val2, exclusive.
>>
>> The type of $val1 and $val2 must be compatible with the type of $node,
>> and must be a derivative of xs:decimal.
>>
>> It is a schema definition error if the $node argument is a complex
>> element.
>>
>>
>>
>> Regards
>>
>> Steve Hanson
>> Architect, *IBM DFDL*
>> <http://www.ibm.com/developerworks/library/se-dfdl/index.html>
>> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
>> IBM SWG, Hursley, UK
>> *smh at uk.ibm.com* <smh at uk.ibm.com>
>> tel:+44-1962-815848
>>
>>
>>
>> From:        Steve Hanson/UK/IBM
>> To:        DFDL-WG <dfdl-wg at ogf.org>
>> Date:        11/08/2015 16:28
>> Subject:        Fw: [DFDL]: First Release of DFDL4S Parser Library
>> ------------------------------
>>
>>
>>
>>
>> Regards
>>
>> Steve Hanson
>> Architect, *IBM DFDL*
>> <http://www.ibm.com/developerworks/library/se-dfdl/index.html>
>> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
>> IBM SWG, Hursley, UK
>> *smh at uk.ibm.com* <smh at uk.ibm.com>
>> tel:+44-1962-815848
>> ----- Forwarded by Steve Hanson/UK/IBM on 11/08/2015 16:27 -----
>>
>> From:        Michele Zundo <michele.zundo at esa.int>
>> To:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
>> Cc:        Steve Hanson/UK/IBM at IBMGB, Maurizio De Bartolomei <
>> Maurizio.De.Bartolomei at esa.int>, Montserrat Piñol <mpinol at eopp.esa.int>,
>> "Rui Mestre (DME)" <rui.mestre at deimos.com.pt>
>> Date:        18/05/2015 08:47
>> Subject:        Re: [DFDL]: First Release of DFDL4S Parser Library
>> ------------------------------
>>
>>
>>
>> Thanks Mike,
>>
>> we will add this to our list to be considered/noted.
>>
>> However reading your explanation (NB I’m NOT at all an XPath expert) it
>> seemed you
>> had some good reason for avoiding longer than 1 path, so I would like to
>> avoid our DFDL4S
>> project results in an over-complication of the DFDL implementation/use of
>> Xpath
>> unless there are other reasons/users/rationale requiring this feature.
>> (btw the syntax is still weird-ish:  “intersect” reminds me of Venn
>> Diagrams…)
>>
>> As a project manager I always evaluate solutions and their cost vs the
>> benefit they bring,
>> and I believe the DFDL community should keep this is mind.
>>
>> Michele
>>
>> PS The syntax above anser to the question “belongs to” , would there be
>> any way to express ranges of values then ?
>>
>>
>>
>> On 15 May 2015, at 16:24 , Mike Beckerle <*mbeckerle.dfdl at gmail.com*
>> <mbeckerle.dfdl at gmail.com>> wrote:
>>
>> Just a few comments on DFDL4S, and also thank you to Michele and team for
>> the presentation on Tuesday.
>>
>> I think all the issues in the spreadsheet are fairly easily fixed in that
>> they are not major changes to DFDL4S, and would bring it into much closer
>> compliance with the DFDL spec.
>>
>> The exception is the XPath limitations where DFDL4S has gone beyond what
>> XPath 2.0 allows and invented new syntax for expressing set membership
>> requirements.
>>
>> So I took a look, and XPath 2.0 has a set intersect operator:  ns1
>> intersect ns2 => ns3
>>
>> This isn't in DFDL today, but might be usable to achieve the set
>> membership test; however, it requires use of XPath node sequences of length
>> greater than 1, which DFDL has avoided mostly. I say mostly as there are
>> XPath expressions that return node sequences of length greater than 1 and
>> those can be arguments to fn:count(...) for example.
>>
>> So far in DFDL such node sequences cannot "leak out" of the XPath
>> expression into DFDL elements, and I think the usage in DFDL4S is similar
>> in that these node sequences would be needed only to check for set
>> membership, so the result is just a boolean as part of an
>> assert/discriminator.
>>
>> We should examine whether XPath 2.0 set intersection is enough to meet
>> the need.
>>
>> I believe the expressions would be something like:
>>
>>      fn:exists( . intersect (123, 456, 789, .... many more items....) )
>>
>>
>> - mike beckerle
>>
>>
>> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
>> *www.tresys.com* <http://www.tresys.com/>
>> Please note: Contributions to the DFDL Workgroup's email discussions are
>> subject to the *OGF Intellectual Property Policy*
>> <http://www.ogf.org/About/abt_policies.php>
>>
>>
>> On Tue, May 12, 2015 at 10:45 AM, Michele Zundo <*michele.zundo at esa.int*
>> <michele.zundo at esa.int>> wrote:
>> for reference,
>> here a summary of the reported problem in an excel sheet.
>>
>> 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.
>>
>>
>>
>>
>> -----------------------------------------
>> Michele Zundo
>>
>> Head of Ground System Definition and Verification Office
>> EOP-PEP
>> European Space Agency, ESTEC
>> e-mail: *michele.zundo at esa.int* <michele.zundo at esa.int>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -----------------------------------------
>> Michele Zundo
>>
>> Head of Ground System Definition and Verification Office
>> EOP-PEP
>> European Space Agency, ESTEC
>> e-mail: *michele.zundo at esa.int* <michele.zundo at 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
>>
>>
>> #### Sentinel2X-bandTMISPTypes.xsd moved to MyAttachments Repository V3.8
>> (Link
>> <notes:///802575AF0030E827/5DE5236E5AD1645685256EE0001BBADF/784AE1CEA59C046380257EAB0027C2EF>)
>> on 24 August 2015 by Steve Hanson.
>>
>>
>>
>> --
>>  dfdl-wg mailing list
>>  dfdl-wg at ogf.org
>>  https://www.ogf.org/mailman/listinfo/dfdl-wg
>>
>>
>> -----------------------------------------
>> Michele Zundo
>>
>> Head of Ground System Definition and Verification Office
>> EOP-PEP
>> European Space Agency, ESTEC
>> e-mail: michele.zundo at 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.
>>
>>
>> --
>>   dfdl-wg mailing list
>>   dfdl-wg at ogf.org
>>   https://www.ogf.org/mailman/listinfo/dfdl-wg
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20150923/81ce818d/attachment-0001.html>


More information about the dfdl-wg mailing list