[DFDL-WG] DFDL WG action 139: Proposed resolution

[Steve Hanson]

Following is the resolution from action 139.

An errata document accompaniment to the DFDL 1.0 specification is under 
production and this will be added to it.

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
----- Forwarded by Steve Hanson/UK/IBM on 05/07/2011 18:26 -----

WG resolution for action 139

a) In-scope delimiters

Clarification: Using lengthKind 'explicit', 'implicit', 'prefixed' or 
'pattern' means that delimiter scanning is turned off and in-scope 
delimiters are not looked for within or between elements.

b) Policing a physical constraint without terminating a parse 

The example cited was using a dfdl:assert to police a physical length 
constraint when lengthKind is 'delimited'.

Addition:
- A new failure type is introduced, 'Recoverable Error', after which the 
parser will continue.
- Importantly, it does not cause backtracking to take place when 
speculating.
- It can be raised via a new enum attribute on dfdl:assert called 
'failureType' - see below.
- An error occurring during evaluation of a dfdl:assert remains a 
Processing Error.
- All existing stated Processing Errors remain as such.
- Discriminators remain unchanged.
- The issuing of Recoverable Errors is independent of whether validation 
is enabled.

Property Name
Description
failureType
Enum (optional)

Valid values are 'processingError',  'recoverableError'.
Default value is 'processingError'.

Specifies the type of failure that occurs when the dfdl:assert is 
unsuccessful. 

When 'processingError', a processing error is raised.

When 'recoverableError', a recoverable error is raised.

Annotation: dfdl:assert

The WG believe the new failure type is genuinely useful going forward as 
it allows the parser or unparser to continue in situations where it was 
unable to do so.

The WG considered extending Validation Error to cover this, but the spec 
is quite clear that these are logical checks performed on the infoset and 
the behaviour of the DFDL processor is unspecified, so it seemed best not 
to change this and to introduce a new failure type.
 






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/20110705/7126452a/attachment.html