[DFDL-WG] Backtracing behavior for optional elements

Steve Hanson smh at uk.ibm.com
Mon Feb 11 09:56:59 EST 2013


If a processing error occurs for an optional element in a sequence, the 
speculative behaviour of the DFDL parser says that the optional element is 
assumed not to be present, and the next alternative in the sequence is 
tried. That is fine when there are no separators involved, but we need to 
clear on what happens when there are separators.

1) Positional separators (separatorSuppressionPolicy is 'never', 
'trailingEmpty' and 'trailingEmptyStrict').
The key point about positional separators is that they are expected in the 
data, so if an error occurs while parsing the optional element, it does 
not make sense to backtrack to the start offset the element and try to 
match the next element. Yes there's a point of uncertainty in the sense 
that the element is either there or it has empty representation, but if an 
error occurs I think it must be treated as a hard error, and not cause 
backtracking. 

2) Non-positional separators (separatorSuppressionPolicy is 'anyEmpty').
This behaves like the non-separator case and the next alternative in the 
sequence is tried from the start offset. However, because 'anyEmpty' 
behavior is lax, it is possible that the next thing in the data is a 
separator, so the parser must cater for that when the element is found to 
have empty representation. But if an error occurs establishing 
representation, I think the parser should just backtrack and try to match 
the next element. 

Does that sound correct?

Regards

Steve Hanson
Architect, Data Format Description Language (DFDL)
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh at uk.ibm.com
tel:+44-1962-815848
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/20130211/84e959a3/attachment.html>


More information about the dfdl-wg mailing list