[DFDL-WG] still no need for fn:error
Mike Beckerle
mbeckerle.dfdl at gmail.com
Tue Jun 14 12:10:26 EDT 2016
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
<http://www.ogf.org/About/abt_policies.php>
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/*
> <http://www.ogf.org/dfdl/dfdl-1.0/>">
> <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* <http://www.ogf.org/dfdl/>
>> IBM SWG, Hursley, UK
>> *smh at uk.ibm.com* <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/*
>> <http://www.ogf.org/dfdl/dfdl-1.0/>">
>> <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* <http://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20160614/7079bde8/attachment.html>
More information about the dfdl-wg
mailing list