[DFDL-WG] Making it easier to create DFDL implementations

Steve Hanson smh at uk.ibm.com
Wed Sep 15 11:56:55 CDT 2010


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 at 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





-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20100915/1a5de485/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Optional_features_v1.pdf
Type: application/octet-stream
Size: 38402 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dfdl-wg/attachments/20100915/1a5de485/attachment-0001.obj 


More information about the dfdl-wg mailing list