Some more thoughts on this.
Even if 4 is changed to a schema definition
error, the normal scoping rules would mean that an occurs property could
still be picked up from a global element if either the global element use
dfdl:ref which pulled in an occurs property, or if the element ref and
it's schema were totally silent about an occurs property but a dfdl:format
in the global element's schema wasn't silent so the global element picked
up a default. As well as the SDE we'd need to make it clear that properties
in 4 must not be picked up from the global element's scope.
----------------------------------------------
Errata 3.8 clarifies what action a DFDL
processor should take when it encounters an object that explicitly carries
properties that are not relevant to the object, as follows:
1 Property
not applicable to the object’s kind.
Schema definition error. Example is
lengthKind on xs:sequence.
2 Property
not applicable because of simple type.
Warning. Example is calendarPatternKind
on xs:string.
3 Property
not applicable because of another DFDL property setting.
Warning.
Example is binaryNumberRep when representation is text
4 Property
not applicable because object is global.
Warning (optional). Example is occursCountKind
on a global xs:element.
I am starting to question whether 4 is
the correct behaviour. I think this should be a schema definition error
and not a warning because the property becomes applicable for an element
reference that refers to that global element. It is a different situation
from the other warning cases 2 & 3, where the test is made once scoping
rules are applied, and the property is therefore not applicable.
Thoughts?
Regards
Steve Hanson
Architect, IBM Data Format Description Language (DFDL)
Co-Chair, OGF
DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848
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