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. 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? 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. 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
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 | <mailto:mbeckerle.dfdl@gmail.com> mbeckerle.dfdl@gmail.com _____ 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
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"/> <!-- 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@gmail.com 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 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
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"/> <!-- 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@gmail.com <mailto:mbeckerle.dfdl@gmail.com> ________________________________ From: Alan Powell [mailto:alan_powell@uk.ibm.com <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 ________________________________ 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
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.ht... 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"/> <!-- 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@gmail.com 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 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
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.ht... 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"/> <!-- 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@gmail.com 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 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
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.ht... 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.ht... 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"/> <!-- 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@gmail.com 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 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
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: dfdl-wg@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@ca.ibm.com From: Steve Hanson <smh@uk.ibm.com> <mailto:smh@uk.ibm.com> To: Suman Kalia/Toronto/IBM@IBMCA Cc: dfdl-wg@ogf.org, "Dave Glick" <dglick@dracorp.com> <mailto: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> <mailto:kalia@ca.ibm.com> Sent by: dfdl-wg-bounces@ogf.org 02/03/2009 16:25 To "Dave Glick" <dglick@dracorp.com> <mailto: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/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@ca.ibm.com From: "Dave Glick" <dglick@dracorp.com> <mailto:dglick@dracorp.com> To: "Alan Powell" <alan_powell@uk.ibm.com> <mailto:alan_powell@uk.ibm.com> , <mbeckerle.dfdl@gmail.com> <mailto: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 <mailto:dglick@dracorp.com> | 703.299.0700 x212 Data Research and Analysis Corp. | www.dracorp.com <http://www.dracorp.com/> ________________________________ From: dfdl-wg-bounces@ogf.org [mailto: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> <mailto:mbeckerle.dfdl@gmail.com> To: Alan Powell/UK/IBM@IBMGB Cc: <dfdl-wg@ogf.org> <mailto: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"/> <!-- 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@gmail.com <mailto:mbeckerle.dfdl@gmail.com> ________________________________ From: Alan Powell [mailto:alan_powell@uk.ibm.com <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 ________________________________ 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 <http://www.ogf.org/mailman/listinfo/dfdl-wg> -- dfdl-wg mailing list dfdl-wg@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@ogf.org http://www.ogf.org/mailman/listinfo/dfdl-wg
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.ht... 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.ht... 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"/> <!-- 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@gmail.com 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 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 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
Folks, I wanted to remind everyone the purpose of dfdl:sequence and the other specialized annotations. The point of these is to allow a XSD for dfdl annotations to provide some value in the following way: 1. Get an XSD-aware XML Editor (e.g., Altova XML Spy). 2. Plug into it the XSD for dfdl annotations. 3. Start editing a DFDL Schema. 4. When you type dfdl:sequence instead of dfdl:format, based on the schema (for DFDL annoataions) information, Altova XML Spy will give you pulldown lists and graphical prompting which will show you only the relevant properties. 5. If you type dfdl:format you get all the properties, little help for narrowing down the list. The whole point: cheap and easy tooling to help author DFDL schemas. This is why these were moved to a later section of the document. They're not needed for the DFDL language per se. They're just there to enable this tooling. Symantically, they mean exactly what dfdl:format means. We could just completely avoid mention of them until that point in the spec., which would perhaps remove the issues of confusion as mentioned by Dave Glick. Here's the reason why we might want to remove them anyway: Too many properties are applicable to these things. Since everything can have text represetnation, and text representation requires a whole bunch of properties, you get a long list of properties for a dfdl:sequence. Not a short list of separator/terminator type properties only. Every property that affects text and character sets applies. Given this, the value of these things gets somewhat diluted. I can go either way with this particular item. At minimum we should reserve all symbols in the dfdl namespace. I think Suman is right that if we don't specify these, then people will create them in various non-standard ways. Mike Beckerle | OGF DFDL WG Co-Chair | CTO | Oco, Inc. Tel: 781-810-2100 | 100 Fifth Ave., 4th Floor, Waltham MA 02451 | <mailto:mbeckerle.dfdl@gmail.com> mbeckerle.dfdl@gmail.com _____ From: dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org] On Behalf Of Steve Hanson Sent: Monday, March 02, 2009 6:45 PM To: Suman Kalia Cc: dfdl-wg@ogf.org 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.h tml> http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.ht ml 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.h tml> http://www.ibm.com/developerworks/websphere/zones/businessintegration/wmb.ht ml 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 | <mailto:dglick@dracorp.com> dglick@dracorp.com | 703.299.0700 x212 Data Research and Analysis Corp. | <http://www.dracorp.com/> www.dracorp.com _____ From: dfdl-wg-bounces@ogf.org [ <mailto: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"/> <!-- 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 | <mailto:mbeckerle.dfdl@gmail.com> mbeckerle.dfdl@gmail.com _____ From: Alan Powell [ <mailto:alan_powell@uk.ibm.com> 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 _____ 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> http://www.ogf.org/mailman/listinfo/dfdl-wg -- dfdl-wg mailing list dfdl-wg@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 _____ 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
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@dracorp.com | 703.299.0700 x212 Data Research and Analysis Corp. | www.dracorp.com ________________________________ From: Suman Kalia [mailto:kalia@ca.ibm.com] Sent: Monday, March 02, 2009 11:25 AM To: Dave Glick Cc: Alan Powell; dfdl-wg@ogf.org; dfdl-wg-bounces@ogf.org; mbeckerle.dfdl@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/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@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 <mailto:dglick@dracorp.com> | 703.299.0700 x212 Data Research and Analysis Corp. | www.dracorp.com <http://www.dracorp.com/> ________________________________ From: dfdl-wg-bounces@ogf.org [mailto: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"/> <!-- 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@gmail.com <mailto:mbeckerle.dfdl@gmail.com> ________________________________ From: Alan Powell [mailto:alan_powell@uk.ibm.com <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 ________________________________ 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 <http://www.ogf.org/mailman/listinfo/dfdl-wg>
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.ht... 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: Suman Kalia/Toronto/IBM@IBMCA Cc: "Alan Powell" <alan_powell@uk.ibm.com>, <dfdl-wg@ogf.org>, <dfdl-wg-bounces@ogf.org>, <mbeckerle.dfdl@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@dracorp.com | 703.299.0700 x212 Data Research and Analysis Corp. | www.dracorp.com From: Suman Kalia [mailto:kalia@ca.ibm.com] Sent: Monday, March 02, 2009 11:25 AM To: Dave Glick Cc: Alan Powell; dfdl-wg@ogf.org; dfdl-wg-bounces@ogf.org; mbeckerle.dfdl@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.ht... 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"/> <!-- 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@gmail.com 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 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
participants (6)
-
Alan Powell -
Dave Glick -
Martin Westhead -
Mike Beckerle -
Steve Hanson -
Suman Kalia