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