ࡱ > '` :7 bjbj . ( }
D
X P 0 = = = = > m V ? @ @ @ @ A V B d GC 4 l l l l l l l $ o h Qr P l
* {C ~ A A C T MD , l
@ @ l X H H H yD l
@
@ l H {C l H H 4c
0e @ ? 2Q = E d k ?m T m d r G r 4 0e r 0e {C {C H {C {C {C {C {C l l H {C {C {C m {C {C {C {C ' d '
Representation Property Scoping Rules
This section describes the rules that govern the scope over which DFDL format annotations apply
The scope of the representational properties on each of the component format annotations is give in REF _Ref243814390 \h Table 1 DFDL annotation scoping
Annotation PointProperty ScopeSchema declarationdfdl:format properties apply lexically over all components in the schema Element declarationdfdl:element properties apply locally Element referencedfdl:element properties apply locallySimple type definitiondfdl:simpleType properties apply locallySequence declarationdfdl:sequence properties apply locallyChoice declarationDfdl:choice properties apply locallyGroup referenceDfdl:group properties apply locallydfdl named defineFormatApply locally on the referencing componentTable SEQ Table \* ARABIC 1 DFDL annotation scoping
Representational properties explicitly defined on annotations other than a dfdl:format on an xs:schema declaration apply locally to that component only. The explicitly defined properties are the combination of any defined locally on the annotation and any defined on the dfdl:defineFormat annotation reference by a local dfdl:ref property.
The dfdl:format annotation on the xs:schema declaration provides defaults for the dfdl properties at every DFDL-annotatable component in the schema document. They do not apply to any components in any included or imported schema document (these may have their own defaults)
Providing Defaults for DFDL properties
A dfdl:format annotation on the top level xs:schema declaration may provide defaults for some or all the dfdl properties at every annotation point within the schema document.
DFDL properties defined explicitly on a component apply only to that component and override the default value of that property provided by a xs:schema dfdl:format annotation.
The example below demonstrates the overriding of a format encoding property. The 'ASCII' dfdl:format encoding is the default value for the title element, but then it is overridden by the locally defined utf-8 format encoding, which takes precedence.
Figure SEQ Figure \* ARABIC 1 Setting defaults for DFDL propeties
Multiple Annotations at the same point
When multiple DFDL annotations occur at the same annotation point then the properties they contain are combined with the later format annotations overriding earlier ones, (later meaning textually later in the schema document) and short-form annotations are interpreted as if they appeared in a long-form annotation that is first before any other long-form annotations.
It is a schema definition error if the same property is defined in long and short form.
Combining DFDL Properties from a dfdl:defineFormat
The DFDL properties contained in a referenced dfd:defineFormat are combined with any DFDL properties defined locally on a construct as if they had been defined locally. before any short form annotations. If the same property is defined locally in short or long form and in the referenced dfdl:defineFormat then the local property takes precedence. The combined set of explicit DFDL properties has precedence over any defaults set by a dfdl:format on the xs:schema.
Figure SEQ Figure \* ARABIC 2 DFDL properties from dfdl:DefineFormat
The example above demonstrates the overriding of an encoding property. The 'ASCII' format encoding from the 'myFormat' is overridden by the UTF-8 format encoding, which as a locally defined property takes precedence.
Combining DFDL Properties from References
The dfdl properties from the following types of reference are combined using the rules below.
an xs:element and its referenced xs:simpleType restriction,
an xs:element reference and its referenced global xs:element
an xs:group reference and an xs:sequence or xs:choice in its referenced global xs:group
an xs:simpleType restriction and its base xs:simpleType restriction
Rules
Create an empty working set of "explicit" properties. Create an empty working set of "default" properties.
Start with the simple type. Assemble its directly relevant "explicit" properties from its local dfdl:ref (if present) and its local properties (if present), the latter overriding the former (that is local wins). Combine these with the current working set of "explicit" properties. It is a schema definition error if there is a property clash. Result is a new working set of "explicit" properties. Obtain directly relevant "default" properties from in-scope unnamed dfdl:format block (if present). Combine these with the current working set of "default" properties, the latter overriding the former (ie, inner wins). Result is a new working set of "default" properties. Move to the global element. Repeat step 2.
Move to the element reference. Repeat step 2.
Validate the resultant set of properties. The "explicit" properties take priority, "defaults" only used when no "explicit" is present. It is a schema definition error if a required property is in neither the "explicit" nor the "default" working sets.
"Directly relevant" properties are all the DFDL properties that apply to that type of schema construct. For example all the DFDL properties that apply to an xs:simpleType.
Figure SEQ Figure \* ARABIC 3 Merging properties from and xs:element and xs:simpleType
The locally defined dfdl:alignment property with value '16' from the xs:simpleType 'newType' is combined with the locally defined dfdl:representation property with value 'binary' and applied to element 'testElement1', along with any defaults set by a dfdl:format on the xs:schema.
Figure SEQ Figure \* ARABIC 4 Merging DFDL properties from a base xs:simpleType
The locally defined dfdl:representation property with value 'binary' is combined with the locally defined dfdl:alignment property with value '64' from the xs:simpleType restriction 'otherNewType'
Figure SEQ Figure \* ARABIC 5 DFDL properties on group reference to xs:group in another schema
The DFDL properties applied to the xs;sequence in xs:group "ggrp1" in SCHEM2 when referenced from the group reference in SCHEMA1 are
dfdl:separator="," from the group reference in SCHEMA1
dfdl:lengthKind="implicit" from the group declaration in SCHEMA2
dfdl:encoding="UTF_8", dfdl:linputValueCalc="", dfdl:outputValueCalc="" , dfdl:initiator=''", dfdl:terminator="" from the default dfdl:format block in SCHEMA2
Nothing from the default dfdl:format block in SCHEMA1
Glossary
Local properties Local properties are the properties defined on an annotation in either short or long form
Explicit properties - The explicit properties are the combination of any defined locally on the annotation and any defined on the dfdl:defineFormat annotation reference by a local dfdl:ref property.
"Directly relevant" properties - All the DFDL properties that apply to that type of schema construct. For example all the DFDL properties that apply to an xs:simpleType.
Not sure what it means.
Add ( with locally defined properties taking precedence over the properties retrieved from referencecd format block
Contained in the schema document
This is somewhat departure from our previous assumption where we stated / implied dfdl:format has to have defaults for all DFDL properties.
The danger for having incomplete format definitions is that the validator will be flagging error on each every element on the schema.
Also For the example schema it would not know how to render the book element does it have text/binary rep etc ?
Add another bullet for element reference for a global element of simple type derived by restriction. In this case are we assuming that there should not be any duplicate annotation on element reference, global element and simple type. Question: what if elemRef is specified on global element and elementRef , wont we have clash all the time.
What if there are multiple model groups as the immediate children of global group definition. Are we going to put this as restriction on DFDL compliant Schema. If not then we have a breakage.
What about the use case where the ref property was defined at otherNewType and newType how these rules will work. We should put an example for that.
Need example of element ref -> element -> simple type.
Need example of dfdl:ref.
AWP>> see first example above
Say there was a separator @ defined in schema 2 then when I view the properties of sequence in schema 2 I would see separator set to @ correct?
The subject schema defined as such is in error because constructs defined in the schema do not have all the required properties.
% & ' i n u
# $ % E F X Y v w ɿ{uiuc{W{ H hě&h/ 0J!
h9q 0J! H hr|چh 0J!
h}PA 0J!
h? 0J! hd hg| 0J" "H hģFho mH nH sH u H hģFho mH nH u j ho Uj ho UH hģFho j H hģFho U hu H hě&h/ h hg| hd hg| hg| h[ h~ & ' % 6 E r $$If a$gdg| l ' $If gdg| l ' d d [$\$gdo gd/ gdg| M
&