[DFDL-WG] representation properties vs. format properties

Mike Beckerle mbeckerle.dfdl at gmail.com
Mon Feb 18 17:26:29 EST 2013


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'.


> - 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20130218/2b32e256/attachment.html>


More information about the dfdl-wg mailing list