[DFDL-WG] Reducing the number of DFDL properties.
Suman Kalia
kalia at ca.ibm.com
Mon Mar 2 15:51:02 CST 2009
>> For example, when annotating an xs:sequence element, whether the user
is using a dfdl:format element or a dfdl:sequence element, they still must
understand which of the superset of representation
>> properties can be applied to the annotation element. The fact that
it’s called “dfdl:format” or “dfdl:sequence” doesn’t make it easier to
understand which representation properties are valid for xs:sequence >>
elements.
That is not exactly true for specialized annotations.. dfdl:format can
have any of the annotation specified in the spec.. but dfdl:sequence will
have only the set of annotations that are applicable to sequence.. This
will be enforced through DFDL model. As an example, in the DFDL model we
would define a dfdl:sequence element and add only dfdl attribute specific
to sequence. It should save time while validating DFDL schema and there
should be savings in DFDL runtime parser also as it would have to look
for restricted set of annotations.
Suman Kalia
IBM Toronto Lab
WMB Toolkit Architect and Development Lead
WebSphere Business Integration Application Connectivity Tools
http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.html
Tel : 905-413-3923 T/L 969-3923
Fax : 905-413-4850 T/L 969-4850
Internet ID : kalia at ca.ibm.com
From:
"Dave Glick" <dglick at dracorp.com>
To:
Suman Kalia/Toronto/IBM at IBMCA
Cc:
"Alan Powell" <alan_powell at uk.ibm.com>, <dfdl-wg at ogf.org>,
<dfdl-wg-bounces at ogf.org>, <mbeckerle.dfdl at gmail.com>
Date:
03/02/2009 01:34 PM
Subject:
RE: [DFDL-WG] Reducing the number of DFDL properties.
Suman,
In regards to your point that not having the specialized annotation
elements will mean that the user has to go through and understand when and
where representation properties are applicable – doesn’t this hold true
one way or the other? For example, when annotating an xs:sequence element,
whether the user is using a dfdl:format element or a dfdl:sequence
element, they still must understand which of the superset of
representation properties can be applied to the annotation element. The
fact that it’s called “dfdl:format” or “dfdl:sequence” doesn’t make it
easier to understand which representation properties are valid for
xs:sequence elements.
In general, the following points are what led me to recommend the special
annotation elements be removed:
- Because a special annotation element can be used interchangeably with
dfdl:format, it is up to the DFDL parser to eventually validate defined
representation properties based on the XML Schema element to which to
annotation applies, regardless of whether the annotation element is a
dfdl:format or one of the special annotation elements (in other words, the
parser can never just trust that the user only defined valid
representation properties simply because they used a special annotation
element such as dfdl:sequence).
- Parsers must recognize and validate both conventions, thus adding an
extra burden on implementations.
- The explanation of the representation properties and where they are
valid gets awkward and confusing. For example, right now a representation
property is said to apply to “dfdl:sequence,” and it is up to the reader
to understand that that also means dfdl:format when used to annotate a
xs:sequence element (and understand they must because using a dfdl:format
is equally valid).
- A reader of a DFDL schema must know that the special annotation elements
are really just dfdl:format annotation elements, thus given them one more
syntactic convention to remember.
- The introduction of two syntactically different ways to mean exactly the
same thing creates a situation where the use of one method over the other
becomes a preference of an individual DFDL schema developer and could make
DFDL schemas more difficult to read and understand by someone used to the
alternate method.
- Multiple types of annotation elements for the description of
representation makes it more difficult to parse a DFDL Schema using XML
technologies. For example, someone may wish to use XSLT to pull out all
the representations defined in a DFDL Schema – if more than one element
for defining representations is used, this stylesheet would be much more
complicated because it would have to deal with all possibilities.
I think my heartburn can be summed up by saying that they seem to me to
add a disproportionate amount of complication compared to the limited
benefit. In fact, it would seem to me that having the concept in the
standard doesn’t actually add anything of value – what is it exactly that
an implementation or DFDL Schema developer can do or do easier with them
that they couldn’t do without?
Dave
---
David Glick | dglick at dracorp.com | 703.299.0700 x212
Data Research and Analysis Corp. | www.dracorp.com
From: Suman Kalia [mailto:kalia at ca.ibm.com]
Sent: Monday, March 02, 2009 11:25 AM
To: Dave Glick
Cc: Alan Powell; dfdl-wg at ogf.org; dfdl-wg-bounces at ogf.org;
mbeckerle.dfdl at gmail.com
Subject: Re: [DFDL-WG] Reducing the number of DFDL properties.
I am not sure what kind of confusion or redundancy is caused by these
specialized annotations. In the absence of these specialized annotations,
you will have to go through plethora of annotations and determine which
ones are applicable for sequence , choice, all, elements etc..
The danger is we don't have these levels of abstractions, then number of
folks (specifically implementers) would build them anyway and then we will
have to contend with incompatible abstractions..
Suman Kalia
IBM Toronto Lab
WMB Toolkit Architect and Development Lead
WebSphere Business Integration Application Connectivity Tools
http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.html
Tel : 905-413-3923 T/L 969-3923
Fax : 905-413-4850 T/L 969-4850
Internet ID : kalia at ca.ibm.com
From:
"Dave Glick" <dglick at dracorp.com>
To:
"Alan Powell" <alan_powell at uk.ibm.com>, <mbeckerle.dfdl at gmail.com>
Cc:
dfdl-wg at ogf.org
Date:
03/02/2009 11:16 AM
Subject:
Re: [DFDL-WG] Reducing the number of DFDL properties.
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 at dracorp.com | 703.299.0700 x212
Data Research and Analysis Corp. | www.dracorp.com
From: dfdl-wg-bounces at ogf.org [mailto:dfdl-wg-bounces at ogf.org] On Behalf
Of Alan Powell
Sent: Monday, March 02, 2009 11:03 AM
To: mbeckerle.dfdl at gmail.com
Cc: dfdl-wg at ogf.org
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 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
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
--
dfdl-wg mailing list
dfdl-wg at ogf.org
http://www.ogf.org/mailman/listinfo/dfdl-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20090302/284ad67b/attachment-0001.html
More information about the dfdl-wg
mailing list