[DFDL-WG] still no need for fn:error - re-assess

Steve Hanson smh at uk.ibm.com
Tue Jul 5 11:49:14 EDT 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20160705/71aec106/attachment-0001.html>


More information about the dfdl-wg mailing list