Action 282 (was Re: Fw: [DFDL]: First Release of DFDL4S Parser Library)
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@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@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@uk.ibm.com <mailto:smh@uk.ibm.com> tel:+44-1962-815848
From: Steve Hanson/UK/IBM To: DFDL-WG <dfdl-wg@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@uk.ibm.com <mailto:smh@uk.ibm.com> tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 11/08/2015 16:27 -----
From: Michele Zundo <michele.zundo@esa.int> To: Mike Beckerle <mbeckerle.dfdl@gmail.com> Cc: Steve Hanson/UK/IBM@IBMGB, Maurizio De Bartolomei <Maurizio.De.Bartolomei@esa.int>, Montserrat Piñol <mpinol@eopp.esa.int>, "Rui Mestre (DME)" <rui.mestre@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@gmail.com <mailto:mbeckerle.dfdl@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@esa.int <mailto:michele.zundo@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@esa.int <mailto:michele.zundo@esa.int>
----------------------------------------- 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
#### 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@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@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.
Hi Michele Thanks for your quick response. The WG discussed this on the call today. In fact, we wondered if the same result could already be achieved using dfdl:checkConstraints() and declaring the enums or range using XSD facets on xs:simpleType restrictions. Have you considered whether dfdl:checkConstraints() achieves what you want? Example: <xs:simpleType name="myRange"> <xs:restriction base="xs:int> <xs:minInclusive value="100"/> <xs:maxInclusive value="200"/> </xs:restriction> </xs:simpleType> <xs:element name="myValue" type="myRange"> <xs:annotation><xs:appinfo ...> <dfdl:assert>dfdl:checkConstraints(.)</dfdl:assert> </xs:appinfo></xs:annotation> </xs:element> Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Michele Zundo <michele.zundo@esa.int> To: dfdl-wg@ogf.org Cc: Rui Mestre <rui.mestre@deimos.com.pt>, Montserrat Piñol <mpinol@eopp.esa.int>, Maurizio De Bartolomei <mdebartolomei@eopp.esa.int> Date: 22/09/2015 17:21 Subject: [DFDL-WG] Action 282 (was Re: Fw: [DFDL]: First Release of DFDL4S Parser Library) Sent by: dfdl-wg-bounces@ogf.org 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@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@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 Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Steve Hanson/UK/IBM To: DFDL-WG <dfdl-wg@ogf.org> Date: 11/08/2015 16:28 Subject: Fw: [DFDL]: First Release of DFDL4S Parser Library Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 11/08/2015 16:27 ----- From: Michele Zundo <michele.zundo@esa.int> To: Mike Beckerle <mbeckerle.dfdl@gmail.com> Cc: Steve Hanson/UK/IBM@IBMGB, Maurizio De Bartolomei < Maurizio.De.Bartolomei@esa.int>, Montserrat Piñol <mpinol@eopp.esa.int>, "Rui Mestre (DME)" <rui.mestre@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@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 Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy On Tue, May 12, 2015 at 10:45 AM, Michele Zundo <michele.zundo@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@esa.int ----------------------------------------- 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 #### Sentinel2X-bandTMISPTypes.xsd moved to MyAttachments Repository V3.8 (Link) on 24 August 2015 by Steve Hanson. -- dfdl-wg mailing list dfdl-wg@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@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@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
I would note that the dfdl:assert can also be on the simple type definition, thereby making the whole thing reusable. 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 1:12 PM, Steve Hanson <smh@uk.ibm.com> wrote:
Hi Michele
Thanks for your quick response. The WG discussed this on the call today.
In fact, we wondered if the same result could already be achieved using dfdl:checkConstraints() and declaring the enums or range using XSD facets on xs:simpleType restrictions.
Have you considered whether dfdl:checkConstraints() achieves what you want?
Example:
<xs:simpleType name="myRange"> <xs:restriction base="xs:int> <xs:minInclusive value="100"/> <xs:maxInclusive value="200"/> </xs:restriction> </xs:simpleType>
<xs:element name="myValue" type="myRange"> <xs:annotation><xs:appinfo ...> <dfdl:assert>dfdl:checkConstraints(.)</dfdl:assert> </xs:appinfo></xs:annotation> </xs: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@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848
From: Michele Zundo <michele.zundo@esa.int> To: dfdl-wg@ogf.org Cc: Rui Mestre <rui.mestre@deimos.com.pt>, Montserrat Piñol < mpinol@eopp.esa.int>, Maurizio De Bartolomei <mdebartolomei@eopp.esa.int> Date: 22/09/2015 17:21 Subject: [DFDL-WG] Action 282 (was Re: Fw: [DFDL]: First Release of DFDL4S Parser Library) Sent by: dfdl-wg-bounces@ogf.org ------------------------------
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@uk.ibm.com* <smh@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@ogf.org* <dfdl-wg@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@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848
From: Steve Hanson/UK/IBM To: DFDL-WG <*dfdl-wg@ogf.org* <dfdl-wg@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@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 11/08/2015 16:27 -----
From: Michele Zundo <*michele.zundo@esa.int* <michele.zundo@esa.int>> To: Mike Beckerle <*mbeckerle.dfdl@gmail.com* <mbeckerle.dfdl@gmail.com>> Cc: Steve Hanson/UK/IBM@IBMGB, Maurizio De Bartolomei < *Maurizio.De.Bartolomei@esa.int* <Maurizio.De.Bartolomei@esa.int>>, Montserrat Piñol <*mpinol@eopp.esa.int* <mpinol@eopp.esa.int>>, "Rui Mestre (DME)" <*rui.mestre@deimos.com.pt* <rui.mestre@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@gmail.com* <mbeckerle.dfdl@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@esa.int* <michele.zundo@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@esa.int* <michele.zundo@esa.int>
----------------------------------------- Michele Zundo
Head of Ground System Definition and Verification Office EOP-PEP European Space Agency, ESTEC e-mail: *michele.zundo@esa.int* <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
#### 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@ogf.org* <dfdl-wg@ogf.org> *https://www.ogf.org/mailman/listinfo/dfdl-wg* <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@esa.int* <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. -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
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@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@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@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@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848
From: Steve Hanson/UK/IBM To: DFDL-WG <dfdl-wg@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@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 11/08/2015 16:27 -----
From: Michele Zundo <michele.zundo@esa.int> To: Mike Beckerle <mbeckerle.dfdl@gmail.com> Cc: Steve Hanson/UK/IBM@IBMGB, Maurizio De Bartolomei < Maurizio.De.Bartolomei@esa.int>, Montserrat Piñol <mpinol@eopp.esa.int>, "Rui Mestre (DME)" <rui.mestre@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@gmail.com* <mbeckerle.dfdl@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@esa.int* <michele.zundo@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@esa.int* <michele.zundo@esa.int>
----------------------------------------- Michele Zundo
Head of Ground System Definition and Verification Office EOP-PEP European Space Agency, ESTEC e-mail: *michele.zundo@esa.int* <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
#### 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@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@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@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
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@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@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@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@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@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848
From: Steve Hanson/UK/IBM To: DFDL-WG <dfdl-wg@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@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 11/08/2015 16:27 -----
From: Michele Zundo <michele.zundo@esa.int> To: Mike Beckerle <mbeckerle.dfdl@gmail.com> Cc: Steve Hanson/UK/IBM@IBMGB, Maurizio De Bartolomei < Maurizio.De.Bartolomei@esa.int>, Montserrat Piñol <mpinol@eopp.esa.int>, "Rui Mestre (DME)" <rui.mestre@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@gmail.com* <mbeckerle.dfdl@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@esa.int* <michele.zundo@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@esa.int* <michele.zundo@esa.int>
----------------------------------------- Michele Zundo
Head of Ground System Definition and Verification Office EOP-PEP European Space Agency, ESTEC e-mail: *michele.zundo@esa.int* <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
#### 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@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@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@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
participants (3)
-
Michele Zundo -
Mike Beckerle -
Steve Hanson