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

Mon Mar 2 17:10:10 CST 2009

I think what Martin said sums it up perfectly and clearly.

Dave

________________________________

From: dfdl-wg-bounces at ogf.org [mailto:dfdl-wg-bounces at ogf.org] On Behalf
Of Martin Westhead
Sent: Monday, March 02, 2009 6:09 PM
To: Suman Kalia
Cc: dfdl-wg at ogf.org
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/wm
b.html
<http://www.ibm.com/developerworks/websphere/zones/businessintegration/w
mb.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: 

Steve Hanson <smh at uk.ibm.com> <mailto:smh at uk.ibm.com>  

To: 

Suman Kalia/Toronto/IBM at IBMCA 

Cc: 

dfdl-wg at ogf.org, "Dave Glick" <dglick at dracorp.com>
<mailto:dglick at 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
Hursley, UK
Internet: smh at uk.ibm.com
Phone (+44)/(0) 1962-815848 

Suman Kalia <kalia at ca.ibm.com> <mailto:kalia at ca.ibm.com>  
Sent by: dfdl-wg-bounces at ogf.org 

02/03/2009 16:25 

To

"Dave Glick" <dglick at dracorp.com> <mailto:dglick at dracorp.com>  

cc

dfdl-wg at ogf.org, dfdl-wg-bounces at ogf.org 

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/wm
b.html
<http://www.ibm.com/developerworks/websphere/zones/businessintegration/w
mb.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> <mailto:dglick at dracorp.com>  

To: 

"Alan Powell" <alan_powell at uk.ibm.com> <mailto:alan_powell at uk.ibm.com> ,
<mbeckerle.dfdl at gmail.com> <mailto: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 <mailto:dglick at dracorp.com>   |
703.299.0700 x212
Data Research and Analysis Corp.  |  www.dracorp.com
<http://www.dracorp.com/>  

________________________________

From: dfdl-wg-bounces at ogf.org [mailto: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>
<mailto:mbeckerle.dfdl at gmail.com>  

To: 

Alan Powell/UK/IBM at IBMGB 

Cc: 

<dfdl-wg at ogf.org> <mailto: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. 

________________________________

From: Alan Powell [mailto:alan_powell at uk.ibm.com
<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
<http://www.ogf.org/mailman/listinfo/dfdl-wg>  --
dfdl-wg mailing list
dfdl-wg at ogf.org
http://www.ogf.org/mailman/listinfo/dfdl-wg
<http://www.ogf.org/mailman/listinfo/dfdl-wg>  

________________________________

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/a1124438/attachment-0001.html 