Although it was minuted in last week's call that we decided to drop specialised annotations, I don't actually recall that was decision on the call.

The proposal below is in accordance with the suggestion by Martin, and echoed by Dave, that we have only specialised annotations for xsd objects.

*Schema object*	*DFDL annotation allowed*	*Notes*
Schema declaration	dfdl:format	Only within an enclosing dfd:defineFormat.
Element declaration	dfdl:element	Just those properties allowed on elements
Element reference	dfdl:element	Just those properties allowed on elements. Overrides dfdl:element properties on global element
Complex type definition	dfdl:complexType	Full dfdl:format properties. For scoping purposes only.
Simple type definition	dfdl:simpleType	Just those properties allowed on simple types.
Sequence declaration	dfdl:sequence	Just those properties allowed on sequences.
Choice declaration	dfdl:choice	Just those properties allowed on choices.
Group reference	dfdl:group	Just those properties allowed on sequence/choice. Overrides dfdl:sequence/dfdl:choice properties on global group sequence/choice model group

An alternative as I previously wrote is to allow dfdl:sequence and dfdl:choice on a group reference.

Group reference (to sequence group) dfdl:sequence Just those properties allowed on sequence/choice.
Overrides dfdl:sequence properties on global group model sequence group
Group reference (to choice group) dfdl:choice Just those properties allowed on sequence/choice.
Overrides dfdl:choice properties on global group model choice group

Although this does not look as good visually, it is worth bearing in mind section 22.2 of the spec:

22.2 Group Reference
A copy of the definition referenced by a group reference is substituted inline for its declaration while combining any DFDL format annotation elements associated with it as given in Section ı10.5. (TBD: xref to scoping?) Processing then proceeds as for an anonymous group declaration.

Note:
The use of specialised annotations relies on the removal of something that we had talked about but not yet reflected in the spec - dfdl:format on global xsd:group definitions. The idea of allowing this came about fairly recently when we changed the rules for hidden objects. I was unhappy that embedded hidden xsd objects within DFDL annotations would make them invisible to a schema validator, so dfdl:hidden was changed to be a reference to a global group containing the hidden objects. I suggested that we could also put scoping annotations on global groups to support scoping within the hidden construct, it seemed a good idea at the time, but it was not fully explored. Thinking it through, because the global group effectively disappears when the reference is resolved, then so does its annotations. I'm therefore happy to retract scoping annotations on global groups if it makes specialised annotations work.

Regards

Steve Hanson
Programming Model Architect
WebSphere Message Brokers
Hursley, UK
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848

From: Steve Hanson/UK/IBM@IBMGB
To: Suman Kalia <kalia@ca.ibm.com>
Cc: dfdl-wg@ogf.org
Date: 02/03/2009 23:45
Subject: Re: [DFDL-WG] Reducing the number of DFDL properties.

Suman

A DFDL annotation on a group reference overrides a DFDL annotation on the content of the model group (ie, sequence, choice), not a DFDL annotation on the global group. It allows you to override the sequence/choice properties at point of use. The DFDL annotation on a global group is like that on a complex type - it is a scoping construct only.

Regards

Steve Hanson
Programming Model Architect
WebSphere Message Brokers
Hursley, UK
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848

Suman Kalia <kalia@ca.ibm.com>

02/03/2009 22:02

To	Steve Hanson/UK/IBM@IBMGB
cc	dfdl-wg@ogf.org, "Dave Glick" <dglick@dracorp.com>
Subject	Re: [DFDL-WG] Reducing the number of DFDL properties.

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
Hursley, UK
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848

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

02/03/2009 16:25

To	"Dave Glick" <dglick@dracorp.com>
cc	dfdl-wg@ogf.org, dfdl-wg-bounces@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/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:	dfdl-wg@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@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 UK Labs, Hursley, Winchester, SO21 2JN, England
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: <dfdl-wg@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"/> 
<xs:element name="anotherElem" type="xs:float"/> 

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@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 UK Labs, Hursley, Winchester, SO21 2JN, England
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 England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-- 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 England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-- 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 England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Group reference (to sequence group)	dfdl:sequence	Just those properties allowed on sequence/choice. Overrides dfdl:sequence properties on global group model sequence group
Group reference (to choice group)	dfdl:choice	Just those properties allowed on sequence/choice. Overrides dfdl:choice properties on global group model choice group

From:	Steve Hanson/UK/IBM@IBMGB
To:	Suman Kalia <kalia@ca.ibm.com>
Cc:	dfdl-wg@ogf.org
Date:	02/03/2009 23:45
Subject:	Re: [DFDL-WG] Reducing the number of DFDL properties.

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