[DFDL-WG] representation properties vs. format properties

[Steve Hanson]

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 at uk.ibm.com
tel:+44-1962-815848



From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     Steve Hanson/UK/IBM at IBMGB, 
Cc:     dfdl-wg at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20130219/d7b7f3f4/attachment.html>