[DFDL-WG] What are the consequences of a failed assert?

[Steve Hanson]

Almost.  A Recoverable Error does not cause backtracking. It was added to 
enable an assert to perform validation that checked the data stream rather 
than just the infoset. For example, checking the max physical length of a 
non-string value. So it has the same effect on the parse as a Validation 
Error. I've corrected your summary.

The definition and description of the different errors is covered in the 
spec by section 2. There have been some errata in this section to clarify 
the behaviour. Some of the wording has been around since early drafts of 
the spec, so any suggestions for improvement are welcome. 

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:   Tim Kimber/UK/IBM at IBMGB
To:     dfdl-wg at ogf.org, 
Date:   03/07/2013 21:51
Subject:        Re: [DFDL-WG] What are the consequences of a failed 
assert?
Sent by:        dfdl-wg-bounces at ogf.org



There are four types of error in DFDL: 
- a Schema Definition Error : The schema itself is not valid. ( at least 
three kinds: xsd not valid, xsd not in the DFLD subset, DFDL annotations 
not following the rules ) 
- A Processing Error : The data cannot be parsed. Or if unparsing, the 
info set cannot be unparsed. 
- A Recoverable Error : ( see the Errata ). This is effectively a 
user-defined form of Validation Error, raised while executing a DFDL 
assert, 
- A Validation Error : The info set does not conform to the XSD 

A Schema Definition Error is immediately fatal. Most of these can be 
detected by the processor before parsing/unparsing begins. 
A Processing Error or a Recoverable Error will cause the parser to 
suppress the error and backtrack to the nearest point of uncertainty. So 
it will only stop the parse if there are no points of uncertainty 
currently active. 
A Recoverable Error does not cause backtracking - the parser continues to 
parse after reporting the error. 
A Validation Error is only reported if validation is enabled in the DFDL 
processor. It does not cause backtracking - the parser continues to parse 
after reporting the error. 

That's the gist of it. Further details from other WG members may follow 
shortly, depending on how accurate I have managed to be. 

regards,

Tim Kimber, DFDL Team,
Hursley, UK
Internet:  kimbert at uk.ibm.com
Tel. 01962-816742 
Internal tel. 37246742




From:        "Garriss Jr., James P." <jgarriss at mitre.org> 
To:        "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>, 
Date:        03/07/2013 19:06 
Subject:        [DFDL-WG] What are the consequences of a failed assert? 
Sent by:        dfdl-wg-bounces at ogf.org 



I have an element with an assert, 
  
           <xsd:element name="Type" dfdl:inputValueCalc="{ 
fn:lower-case(../MixedCaseType) }">
               <xsd:annotation>
                   <xsd:appinfo source="http://www.ogf.org/dfdl/dfdl-1.0/"
>
                       <dfdl:assert test="{ dfdl:checkConstraints(.) }" 
message="The type must match one of the values on the enumerated list."/>
                   </xsd:appinfo>
               </xsd:annotation>
               <xsd:simpleType>
                   <xsd:restriction base="xsd:string">
                       <xsd:enumeration value="application"/>
                       <xsd:enumeration value="multipart"/>
                       <xsd:enumeration value="message"/>
                       <xsd:enumeration value="text"/>
                   </xsd:restriction>
               </xsd:simpleType>
           </xsd:element> 
  
and the assert is failing (as it should in this case!).   
  
Parse Error: Assertion failed. The type must match one of the values on 
the enumerated list. 
  
What are the consequences of a failed assert?  I have an old version of 
the spec—is there a place to a get a current, complete copy?—but it says 
“An unsuccessful dfdl:assert causes a processing error.”   
  
1.     What does “processing error” mean in English?   
2.     Does it mean the input is invalid?   
3.     Does it mean the processor should stop here and go no further?   
4.     Does it mean the process should simply ignore the problem and move 
on to the next item in the schema?   
  
TIA 
 --
 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
--
  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/20130704/24aeedd4/attachment.html>