I think what Martin said sums it up
perfectly and clearly.
Dave
From: dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org] On Behalf Of Martin Westhead
Sent: Monday, March 02, 2009 6:09
PM
To: Suman Kalia
Cc:
Subject: Re: [DFDL-WG] Reducing
the number of DFDL properties.
I think there are two approaches
that make sense. One is to mandate specializations everywhere, that is to say
within any xs:foo the only
acceptable annotation is dfdl:foo. The other, as Dave suggests, is to just
stick with dfdl:format. I think anything else is just making everybody have to
work harder than they should.
Martin
Suman Kalia wrote:
I can see where you are coming from and I agree with
most of your proposal except putting dfdl:sequence, dfdl:choice , dfdl:all on
group references as it does not give the right optics.. From consistency point
of view, the references (group and element references) should have the
equivalent/same set of annotations that can appear on the referenced artifacts.
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@ca.ibm.com
|
From:
|
Steve Hanson <smh@uk.ibm.com> |
|
To:
|
Suman Kalia/Toronto/IBM@IBMCA
|
|
Cc:
|
dfdl-wg@ogf.org, "Dave Glick" <dglick@dracorp.com>
|
|
Date:
|
03/02/2009 12:45 PM
|
|
Subject:
|
Re: [DFDL-WG] Reducing the
number of DFDL properties. |
If I recall, one reason for having the specialised elements was so that the
content of the annotations could be more tightly validated by the
schema-for-dfdl xsd.
However, the problem with the specialised annotations is that we do not provide
them for all circumstances. For example, the spec allows me to use
dfdl:sequence on an xs:sequence but not an xs:group reference to a global
xs:group with compostion xs:sequence. Nor does it allow me to use a
specialised element on xs:simpleType or xs:restriction. So as it stands,
validation would not be fool-proof anyway.
I think we must either ditch specialisations, or mandate the use of
specialisations on the corresponding schema objects. The latter is more
workable now we have changed the scoping rules so that scoping of dfdl
properties can only be done from complex type or schema level, as below.
But it does mean that dfdl annotations are less flexible.
dfdl;defineFormat => dfdl:format
xs:complexType => dfdl:format
xs:group => dfdl:format
xs:sequence or xs:group ref to a global group with xs:sequence =>
dfdl:sequence
xs:choice or xs:group ref to a global group with xs:choice =>
dfdl:choice
xs:element or xs:element ref => dfdl:element
xs:any => dfdl:any
xs:simpleType, xs:restriction => dfdl:simpleType
In other words, you use dfdl:format when you are scoping properties, you must
use specialised annotation for specific objects.
Regards
Steve Hanson
Programming Model Architect
WebSphere Message Brokers
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848
|
Suman Kalia <kalia@ca.ibm.com> 02/03/2009 16:25 |
|
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@ca.ibm.com
|
From:
|
"Dave Glick" <dglick@dracorp.com>
|
|
To:
|
"Alan Powell" <alan_powell@uk.ibm.com>, <mbeckerle.dfdl@gmail.com>
|
|
Cc:
|
|
|
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@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: mbeckerle.dfdl@gmail.com
Cc: dfdl-wg@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
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" <mbeckerle.dfdl@gmail.com>
|
|
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: mbeckerle.dfdl@gmail.com
Cc: dfdl-wg@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
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:
--
dfdl-wg mailing list
dfdl-wg@ogf.org
http://www.ogf.org/mailman/listinfo/dfdl-wg
--
dfdl-wg mailing list
dfdl-wg@ogf.org
http://www.ogf.org/mailman/listinfo/dfdl-wg
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in
Registered office:
-- dfdl-wg mailing list dfdl-wg@ogf.org http://www.ogf.org/mailman/listinfo/dfdl-wg