In order to make it easier to create powerful conformant implementations of DFDL parsers, here are some proposals:

1) A DFDL unparser is optional.

This recognises that many users of DFDL are using it to understand existing files of data, and not for updating and rewriting that data in its original form.

2) Some advanced DFDL features are optional

The spec defines an additional kind of error called 'unsupported error' which must be generated if an unsupported optional feature is encountered while processing.  

The table below is a proposed list of optional features, and how the use of each such feature is detected by a DFDL processor. Most are detected either by a DFDL property enum value, or a DFDL property being other than the empty string.  This proposal needs no extra properties to define and/or control optional features.

Optional features may have an implied ordering, for example, without simple type restrictions, prefixed lengths are not possible.

It is extremely desirable for a valid DFDL schema used with implementation X to work with any other implementation that implements the same or a wider subset.  This means that all implementations must check for all properties that apply to a DFDL annotation point, including properties for optional features, even if it is just to ensure the property is set to the empty string.  This is a corollary of having no defaults - you can not be silent about a DFDL property.

I do not want to dilute the portability of DFDL schemas by expanding the list of optional features such that large swathes of the spec are removed. For example, making all binary representation optional.  DFDL is not a format.  People who have some data they wish to parse will not write a DFDL parser - they will write a custom parser for their format(s). It's only people who have a wide range of formats, or who want to make money, that will write DFDL parsers.  The core DFDL features must still provide a powerful binary and text modelling capability.

The list of optional features is no way dictates the usability features of DFDL editor tools.  Such tools can offer tailored usability for different data formats if desired. This is orthogonal to optional features.



Regards

Steve Hanson
Strategy, Common Transformation & DFDL
Co-Chair, OGF DFDL WG
IBM SWG, Hursley, UK,
smh@uk.ibm.com,
tel +44-(0)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