[DFDL-WG] still no need for fn:error - re-assess
Steve Hanson
smh at uk.ibm.com
Wed Aug 3 14:36:46 EDT 2016
Yes we could define specific QNames for each. But is the user allowed to
use fn:error() with any other QNames? There are a bunch defined. And if
so, what does that mean in terms of PE v SDE ? Maybe we should restrict
use just to our DFDL QNames.
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: 03/08/2016 14:53
Subject: Re: [DFDL-WG] still no need for fn:error - re-assess
It would certainly be valuable to throw an SDE as well as a PE. When
unparsing there isn't much diffierence since both are fatal, but when
parsing it's quite important.
I suppose we could use the QName argument as a means of distinguishing
these two types of error?
...mikeb
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 Wed, Aug 3, 2016 at 5:34 AM, Steve Hanson <smh at uk.ibm.com> wrote:
Agreed that fn:error() looks suitable. Is the assumption that it always
throws a PE, or do we want the ability to throw an SDE as well ?
I ask because section 23 maps all but one XPath error to SDE.
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: 06/07/2016 14:02
Subject: Re: [DFDL-WG] still no need for fn:error - re-assess
I recall now that QName is a subtype of string, so it's just a kind of
string.
So I agree. I guess fn:error can be used as per XPath without
modification.
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 Wed, Jul 6, 2016 at 5:32 AM, Steve Hanson <smh at uk.ibm.com> wrote:
Mike
True that xs:QName is not a type that is supported as the simple type of
an element, but we do use QNames elsewhere in DFDL schema, eg, in element
refs, type references, as the type of some DFDL properties (eg, dfdl:ref,
dfdl:hiddenGroupRef, dfdl:prefixLengthType), to reference variables in
expressions, ... So I don't see a problem with having a function
argument being a QName.
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: 05/07/2016 19:08
Subject: Re: [DFDL-WG] still no need for fn:error - re-assess
So the fn:error() XPath function takes a problematic argument.
All the arguments are optional, so fn:error() is legal.
The first argument is of type xs:qQName, and we don't have that type in
DFDL. So the best we could do is to accept a string that is in the "form"
of a QName, e.g.,
"foo:bar".
The second argument is a description string, third and subsequent args are
objects. The manner by which this string and objects are provided to the
execution environment is implementation dependent according to the XQuery
and XPath spec, and this is fine for DFDL implementations also.
The lack of the QName type for the first argument suggests we're going to
need to create dfdl:error(string, string, item()*), where the first
argument is a string in the form of a QName, and the other arguments are
as per fn:error.
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 5, 2016 at 11:49 AM, Steve Hanson <smh at uk.ibm.com> wrote:
WG agreed that an error function is needed, action 288 raised.
No
Action
288
Decide on error function specification (Mike)
5/7: An error function is useful for expressions when unparsing. Mike to
evaluate XPath fn:error().
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: 14/06/2016 17:10
Subject: Re: [DFDL-WG] still no need for fn:error
Sent by: "dfdl-wg" <dfdl-wg-bounces at ogf.org>
I want to re-open the discussion of fn:error.
Previously we said it was not needed because an assert could be used.
However, we've now run into where we want to cause an error, during
unparsing, during outputValueCalc.
<xs:element name="Protocol" type="pcap:bit" dfdl:length="8"
dfdl:outputValueCalc="{
if (fn:exists(../../pcap:ICMPv4)) then 1
else if (fn:exists(../../pcap:TransportLayer/pcap:TCP )) then 6
else if (fn:exists(../../pcap:TransportLayer/pcap:UDP )) then
17
else -1 }"/>
That -1 at the end. That's an error case. We really want
fn:error("Unrecognized protocol.")
We can't change to a dfdl:assert, because assertions aren't evaluated when
unparsing.
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
On Thu, Jul 25, 2013 at 9:16 AM, Mike Beckerle <mbeckerle.dfdl at gmail.com>
wrote:
Respin of this example:
Here's the example as suggested by Jonathan of how to issue an error that
I previously was suggesting needed fn:error. I'm convinced this is
sufficient and we can avoid the need for fn:error now.
<xs:element name="magic_number" type="ex:uint32"
dfdl:byteOrder="bigEndian">
<xs:annotation>
<xs:appinfo source="http://www.ogf.org/dfdl/">
<dfdl:assert
test="{ (xs:unsignedInt(.) eq dfdl:unsignedInt('xa1b2c3d4')) |
(xs:unsignedInt(.) eq dfdl:unsignedInt('xd4c3b2a1')) }"
message="{ fn:concat(
'Magic number ',
dfdl:hexBinary(dfdl:unsignedInt(.)),
' was not 0xA1B2C3D4 (for bigEndian) or 0xD4C3B2A1
(for littleEndian).' }" />
<dfdl:setVariable ref="ex:bOrd">{ xs:unsignedInt(.) }<dfdl:setVariable>
</xs:appinfo>
</xs:annotation>
</xs:element>
On Wed, Jul 24, 2013 at 11:58 AM, Steve Hanson <smh at uk.ibm.com> wrote:
Mike, I think you meant:
test="{ (xs:unsignedInt(.) eq dfdl:unsignedInt('xa1b2c3d4')) |
(xs:unsignedInt(.) eq dfdl:unsignedInt('xd4c3b2a1')) }"
Regards
Steve Hanson
Architect, IBM Data Format Description Language (DFDL)
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh at uk.ibm.com
tel:+44-1962-815848
From: Mike Beckerle <mbeckerle.dfdl at gmail.com>
To: dfdl-wg at ogf.org,
Date: 24/07/2013 16:46
Subject: [DFDL-WG] still no need for fn:error
Sent by: dfdl-wg-bounces at ogf.org
Here's the example as suggested by Jonathan of how to issue an error that
I previously was suggesting needed fn:error. I'm convinced this is
sufficient and we can avoid the need for fn:error now.
<xs:element name="magic_number" type="ex:uint32"
dfdl:byteOrder="bigEndian">
<xs:annotation>
<xs:appinfo source="http://www.ogf.org/dfdl/">
<dfdl:assert
test="{ (xs:unsignedInt(.) eq dfdl:unsignedInt('xa1b2c3d4')) |
(xs:unsignedInt(.) eq dfdl:unsignedInt('xd4c3b2a1')) }"
message="{ fn:concat(
'Magic number ',
dfdl:hexBinary(dfdl:unsignedInt(.)),
' was not 0xA1B2C3D4 (for bigEndian) or 0xD4C3B2A1
(for littleEndian).' }" />
<dfdl:setVariable ref="ex:bOrd">{ xs:unsignedInt(.) }<dfdl:setVariable>
</xs:appinfo>
</xs:annotation>
</xs:element>
--
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
www.tresys.com
--
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
--
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
www.tresys.com
--
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
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/20160803/9413fa78/attachment-0001.html>
More information about the dfdl-wg
mailing list