Alan/Mike,
I agree with this – one of my complaints
with v033 was that these specialized annotation elements just added confusion
and redundancy.
Dave
---
David Glick | dglick@dracorp.com
| 703.299.0700 x212
Data Research and Analysis Corp. | www.dracorp.com
From:
dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org] On Behalf Of Alan Powell
Sent: Monday, March 02, 2009 11:03
AM
To:
Cc:
Subject: Re: [DFDL-WG] Reducing
the number of DFDL properties.
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
Notes Id: Alan Powell/UK/IBM email: alan_powell@uk.ibm.com
Tel: +44 (0)1962 815073
Fax: +44 (0)1962 816898
|
From:
|
"Mike Beckerle" < |
|
To:
|
Alan Powell/UK/IBM@IBMGB |
|
Cc:
|
< |
|
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 |
From: Alan
Powell [mailto:alan_powell@uk.ibm.com]
Sent: Thursday, February 26, 2009 12:22 PM
To:
Cc:
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
Notes Id: Alan Powell/UK/IBM email: alan_powell@uk.ibm.com
Tel: +44 (0)1962 815073
Fax: +44 (0)1962 816898
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in
Registered office:
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in
Registered office: