Re: [DFDL-WG] representation properties vs. format properties
I'd like to close this out on the next WG call please. Recommendation is below. 202 Term 'representation property' (All) 29/1: Two kinds of format property, how best to distinguish them in the spec. 5/2: Continued the discussion around 'representation' and 'format'. As part of Steve's review of the spec he will look at this issue and make a recommendation. 12/2: Steve has made a recommendation. Also has recommended that the DFDL spec uses 'property' instead of 'attribute' when referring to XSD properties like minOccurs (technically they are properties with an atribute representation). Review for next call. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Steve Hanson/UK/IBM To: dfdl-wg@ogf.org, Cc: Mike Beckerle <mbeckerle.dfdl@gmail.com> Date: 12/02/2013 14:20 Subject: Re: [DFDL-WG] representation properties vs. format properties I have looked at this as part of my recent review of the updated DFDL spec. My conclusions: - The term 'DFDL property' applies to all DFDL properties carried on any DFDL annotation. We should use it in preference to 'attribute' even when an XML attribute is the only way that a DFDL property may be specified. (This is in keeping with XML Schema, where for example the 'name' property of a component is given by an XML attribute representation 'name'). - Similarly, the term 'XSD property' applies to all XML Schema properties, such as default, fixed, minOccurs, maxOccurs, etc. - The term 'format property' applies to all DFDL properties carried on DFDL format annotations. (One could envisage similar terms 'statement property' and 'defining property' but we don't need them at the moment). - The term 'representation property' applies to all format properties that are used to describe grammar regions. The revised grammar uses 'Rep' in grammar terms like 'SimpleElementEmptyRep' etc. - The term 'non-representation property' applies to all format properties that are not representation properties, specifically dfdl:ref, dfdl:hiddenGroupRef, dfdl:elementId, dfdl:choiceBranchRef, dfdl:inputValueCalc, dfdl:outputValueCalc, dfdl:escapeSchemeRef. The one non-standard property is dfdl:escapeSchemeRef, because it is a non-representation property yet can still be placed into scope. All the other non-representation properties can not be placed into scope. I am ok with that, it just means that whether a format property is a non-representation property is decoupled from whether it can be placed into scope or not, and should be considered on a case-by-case basis. Alternatively we can say that dfdl:escapeSchemeRef is a representation property even though it points at a defining annotation (and so is similar in this respect to dfdl:prefixLengthType). - Property dfdl:representation must be qualified by the namepace prefix when referred to in the spec, and preferably either preceded by 'property' or used on its own, rather than followed by 'property', to avoid any ambiguity. The term 'attribute' should be used only when describing how a property is represented in XML terms. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Steve Hanson/UK/IBM To: Mike Beckerle <mbeckerle.dfdl@gmail.com>, Cc: dfdl-wg@ogf.org, dfdl-wg-bounces@ogf.org Date: 29/01/2013 10:12 Subject: Re: [DFDL-WG] representation properties vs. format properties We do have an actual problem in the spec, as the term 'representation property' is being used to mean both any DFDL property (other than 'ref') and also the property 'representation'. This is best seen in Table 13.1. However I am only seeing one example of the term 'format property' - in section 24 ? Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org, Date: 28/01/2013 18:27 Subject: [DFDL-WG] representation properties vs. format properties Sent by: dfdl-wg-bounces@ogf.org We use both the terms representation property and format property extensively. Do we want to declare these to mean the same thing as each other, or globally replace one with the other. -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com -- dfdl-wg mailing list dfdl-wg@ogf.org https://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 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 annotation. We should use it in preference to 'attribute' even when an XML attribute is the only way that a DFDL property may be specified. (This is in keeping with XML Schema, where for example the 'name' *property* of a component is given by an *XML attribute* *representation* 'name').
The above is very good, because we have even more ways to represent DFDL
This proposal is a very good solution to all these terminology issues - The term 'DFDL property' applies to all DFDL properties carried on any properties, having long, short, and element forms.
*- *Similarly, the term 'XSD property' applies to all XML Schema properties, such as default, fixed, minOccurs, maxOccurs, etc.
This is very useful, because in the spec we aren't consistent here.
- The term 'format property' applies to all DFDL properties carried on DFDL format annotations. (One could envisage similar terms 'statement property' and 'defining property' but we don't need them at the moment).
I'm ok with this.
- The term 'representation property' applies to all format properties that are used to describe grammar regions. The revised grammar uses 'Rep' in grammar terms like 'SimpleElementEmptyRep' etc.
So, is encoding a representation property? Is representation a representation property? I am not quite sure what it means to 'describe grammar regions'.
- The term 'non-representation property' applies to all format properties that are not representation properties, specifically dfdl:ref, dfdl:hiddenGroupRef, dfdl:elementId, dfdl:choiceBranchRef, dfdl:inputValueCalc, dfdl:outputValueCalc, dfdl:escapeSchemeRef.
Is that list exhaustive? I think escapeSchemeRef is a representation property.
The one non-standard property is dfdl:escapeSchemeRef, because it is a non-representation property yet can still be placed into scope. All the other non-representation properties can not be placed into scope. I am ok with that, it just means that whether a format property is a non-representation property is decoupled from whether it can be placed into scope or not, and should be considered on a case-by-case basis. Alternatively we can say that dfdl:escapeSchemeRef is a representation property even though it points at a defining annotation (and so is similar in this respect to dfdl:prefixLengthType).
I think we should say that escapeSchemeRef is a representation property, which eliminates the scope/non-scope issue. I think the analogy to prefixLengthType is very close. Since delimiter properties are representation properties, then so should escapeSchemeRef as it is effectively a modifier on the delimiter properties.
- Property dfdl:representation must be qualified by the namepace prefix when referred to in the spec, and preferably either preceded by 'property' or used on its own, rather than followed by 'property', to avoid any ambiguity.
The term 'attribute' should be used only when describing how a property is represented in XML terms.
Mike, thanks for comments, replies in-line below. Regards Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh@uk.ibm.com tel:+44-1962-815848 From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Steve Hanson/UK/IBM@IBMGB, Cc: dfdl-wg@ogf.org Date: 18/02/2013 22:26 Subject: Re: [DFDL-WG] representation properties vs. format properties This proposal is a very good solution to all these terminology issues - The term 'DFDL property' applies to all DFDL properties carried on any DFDL annotation. We should use it in preference to 'attribute' even when an XML attribute is the only way that a DFDL property may be specified. (This is in keeping with XML Schema, where for example the 'name' property of a component is given by an XML attribute representation 'name'). The above is very good, because we have even more ways to represent DFDL properties, having long, short, and element forms. - Similarly, the term 'XSD property' applies to all XML Schema properties, such as default, fixed, minOccurs, maxOccurs, etc. This is very useful, because in the spec we aren't consistent here. - The term 'format property' applies to all DFDL properties carried on DFDL format annotations. (One could envisage similar terms 'statement property' and 'defining property' but we don't need them at the moment). I'm ok with this. - The term 'representation property' applies to all format properties that are used to describe grammar regions. The revised grammar uses 'Rep' in grammar terms like 'SimpleElementEmptyRep' etc. So, is encoding a representation property? Is representation a representation property? I am not quite sure what it means to 'describe grammar regions'. SMH: Yes to both. I struggled to come up with a condensed phrase to describe what representation properties cover. I was trying to say that the term applies to all format properties that are used when taking some data in the data stream, parsing it and creating the infoset (and vice versa when serializing), and not to properties that are used for schema linkage or to synthesise infoset values. - The term 'non-representation property' applies to all format properties that are not representation properties, specifically dfdl:ref, dfdl:hiddenGroupRef, dfdl:elementId, dfdl:choiceBranchRef, dfdl:inputValueCalc, dfdl:outputValueCalc, dfdl:escapeSchemeRef. Is that list exhaustive? SMH: I believe so. The one non-standard property is dfdl:escapeSchemeRef, because it is a non-representation property yet can still be placed into scope. All the other non-representation properties can not be placed into scope. I am ok with that, it just means that whether a format property is a non-representation property is decoupled from whether it can be placed into scope or not, and should be considered on a case-by-case basis. Alternatively we can say that dfdl:escapeSchemeRef is a representation property even though it points at a defining annotation (and so is similar in this respect to dfdl:prefixLengthType). I think we should say that escapeSchemeRef is a representation property, which eliminates the scope/non-scope issue. I think the analogy to prefixLengthType is very close. Since delimiter properties are representation properties, then so should escapeSchemeRef as it is effectively a modifier on the delimiter properties. SMH: I am ok with that. - Property dfdl:representation must be qualified by the namepace prefix when referred to in the spec, and preferably either preceded by 'property' or used on its own, rather than followed by 'property', to avoid any ambiguity. - The term 'attribute' should be used only when describing how a property is represented in XML terms. 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
participants (2)
-
Mike Beckerle -
Steve Hanson