In the DFDL spec., the problem exists of how to express the behavior of a construct in the situation where there are properties in scope surrounding the construct. Because of the large degree of simplification that the latest scoping rule change implies, (this being that properties are local unless placed on complexType forms), I believe this kind of syntax can be used in the spec. to make clear the implications of scope: <complexType dfdl:lengthKind="implicit" dfdl:representation="text" > // these are in the scope .... <sequence dfdl:separator="," dfdl:terminator=";" dfdl:lengthKind="delimited"> // these are local <element name="f1" type="string" /> <element name="f2" type="string" /> </sequence> .... </complexType> Notice my use of an enclosing complexType and ellipsis in order to achieve the notion that certain property bindings surround the example in the scope. There are some implicit things going on here. The "...." ellipsis doesn't mean "anything", it means "anything except something that changes the scoped properties" because that's the whole point of the illustration here after all! It was previously proposed by Sandy Gao, that we adopt the XSD Schema Components, and the notations they use in the specs that use them, as a means to specify DFDL semantics. The schema components have a model, and specs which discuss them must have a textual syntax for discussing instances of the model. They give the semantics of XSD in terms of translation of the XSD syntax into the model, then the semantics in terms of the model instances. This syntax for the schema components model is specifically not XSD. A key reason XSD needed this two-level approach is that they have the job of explaining XSD Schema syntax, namespaces, import/include/redefine (and now override in 1.1). By adoping the schema components model they can dispense with all issues about how multiple schema documents are assembled into a single "schema" consisting of a collection of schema components. Then they can get to the task of explaining what the collection of schema components means. Now, to me it is quite problematic to express DFDL semantics in terms of an entire intermediate language we create just because XSD did it this way. We don't need to explain the way namespaces and multi-file schema composition work. XSD has already done this. We want DFDL's spec not to reproduce that work, but to just assume that is understood from the XSD work, and focus on what is unique about DFDL. I would prefer to appeal to reason here, express the semantics in terms of familiar DFDL syntactic elements. I believe there is one tricky issue: element reference, and group reference. This is the issue of the properties being combined, so that annotions on the reference override annotations on the top level of the declaration. I believe we can describe this sufficiently without adopting a whole two-layer model. It's not worth it just for this. I lied. There is a second tricky issue: recursive types - however, we've ruled these out of DFDL v1.0, so we're ok here. Comments? Mike Beckerle | OGF DFDL WG Co-Chair | CTO | Oco, Inc. Tel: 781-810-2100 | 504 Totten Pond Road, Waltham MA 02451 | <mailto:mbeckerle.dfdl@gmail.com> mbeckerle.dfdl@gmail.com