[DFDL-WG] Reducing the number of DFDL properties.

Mon Mar 2 10:02:32 CST 2009

Mike

Thanks

Can I also suggest dropping the dfdl:sequence, dfdl:choice, dfdl:element 
and dfdl:any specialized annotations and just have dfdl:format.

Alan Powell

 MP 211, IBM UK Labs, Hursley,  Winchester, SO21 2JN, England
 Notes Id: Alan Powell/UK/IBM     email: alan_powell at uk.ibm.com 
 Tel: +44 (0)1962 815073                  Fax: +44 (0)1962 816898

From:
"Mike Beckerle" <mbeckerle.dfdl at gmail.com>
To:
Alan Powell/UK/IBM at IBMGB
Cc:
<dfdl-wg at ogf.org>
Date:
28/02/2009 19:38
Subject:
RE: Reducing the number of DFDL properties.

If a property is redundant, I'm in favor of dropping it.

If a property adds generality that we don't have a use case for, I'm in 
favor of dropping it.

I am happy to drop type substitution from v1.0. It's a convenience that 
can be achieved a different way.

E.g., if you really want "float" to mean "float in my particular binary 
representation", then just put a type definition with DFDL annotations in 
a different namespace, and when you write your DFDL schema, arrange for 
the default namespace to pick it up from your namespace, and not xs:float. 

<xs:element name="myElement" type="float"/> <!-- float here is 
myNamespace:float which can have DFDL annotations on it -->
<xs:element name="anotherElem" type="xs:float"/> <!-- explicitly xs:float 
without further adornment -->

If you want the XSD unadorned "float" type, be explicit and use 
"xs:float". Voila - no loss of flexibility, equal textual convenience.

I think that would satisfy the community that really wanted very compact 
"slideware acceptable" schemas. This is the same group that wants 
short-form annotations as well. 
Mike Beckerle | OGF DFDL WG Co-Chair | CTO | Oco, Inc.
Tel:  781-810-2100  | 100 Fifth Ave., 4th Floor, Waltham MA 02451 | 
mbeckerle.dfdl at gmail.com 

From: Alan Powell [mailto:alan_powell at uk.ibm.com] 
Sent: Thursday, February 26, 2009 12:22 PM
To: mbeckerle.dfdl at gmail.com
Cc: dfdl-wg at ogf.org
Subject: Reducing the number of DFDL properties.

Mike 

A number of people at IBM have become concerned at the number of 
properties in DFDL and have identified a number of 'usability' properties 
that could be dropped. They feel that we should be simplifying the 
properties wherever possible and not introducing multiple ways of doing 
the same function without very good reason. 

The following are offered for consideration. 
1.      lengthKind='nullterminated'
This is just shorthand for lengthKind=delimited and terminator='%Null'. It 
was felt this this is not even the most common terminator so why have a 
special case? 
2.      trimKind
It is felt that there aren't any cases when you would want to pad but not 
trim and vice versa so make padKind control both. 
3.      typeSubstitution.
Is this needed in DFDL v1?

Can you consider these before the call next week 

Alan Powell

MP 211, IBM UK Labs, Hursley,  Winchester, SO21 2JN, England
Notes Id: Alan Powell/UK/IBM     email: alan_powell at uk.ibm.com 
Tel: +44 (0)1962 815073                  Fax: +44 (0)1962 816898

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/20090302/901e5b14/attachment-0001.html 