Hmmm. This is the dilemma of is an object different from an instance of its type. E.g., if a complex type has a terminator is that the terminator on the element that has that type? We could define the syntax you used as redundant: <element name="foo" dfdl:ref="a"> <complexType dfdl:ref="a"> // means same thing as if also hoisted onto the element having this type. // i.e., ref applies to scope of complexType AND to elements having this type. ... It is true we do not allow dfdl:ref on the xs:schema element. This is for very important reasons of keeping us out of the whole lexical vs. non-lexical scoping morass. Let's not go there. Mike Beckerle | OGF DFDL WG Co-Chair | CTO | Oco, Inc. Tel: 781-810-2125 | 100 Fifth Ave., 4th Floor, Waltham MA 02451 | <mailto:mbeckerle.dfdl@gmail.com> mbeckerle.dfdl@gmail.com _____ From: dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org] On Behalf Of Steve Hanson Sent: Wednesday, May 06, 2009 1:22 PM To: dfdl-wg@ogf.org Subject: [DFDL-WG] DFDL: Applying DFDL annotations to elements To apply DFDL annotations to a top-level element in a DFDL xsd, most modellers would use the dfdl:element dfdl:ref property to refer to a named dfdl:defineFormat block that set up the necessary defaults for all the DFDL properties. To avoid having to re-state the dfdl:ref property on every object that comprises the format, most modellers would also use the dfdl:complexType dfdl:ref property to scope the same dfdl:defineFormat block. The xsd would look like below. <xs:schema ...> <xs:annotation><xs:appinfo source="http://www.ogf.org/dfdl/"> <dfdl:defineFormat name="textFormat1"> <dfdl:format encoding="utf-8" separator="\n" representation="text" lengthKind="delimited" /> </dfdl:defineFormat> </xs:appinfo></xs:annotation> ... <xs:element name="textDoc" dfdl:ref="textFormat1" dfdl:lengthKind="implicit"> <xs:complexType dfdl:ref="textFormat1"> <xs:sequence> ... </xs:sequence> </xs:complexType> </xs:element> ... </xs:schema> It's not possible to put DFDL defaults in scope for the whole format with a single dfdl:ref property. I think this is a side-effect of removing the dfdl:appliesTo property. If this is thought to be an issue, there are a couple of options: One is to say that a complex type can be the top-level object. This is the case with several XML based systems. It works with XML because the XML instance document provides the name of top level element in the infoset via its tag. This is not the case with DFDL where the name is commonly not carried with the format. So we'd have no name for the infoset. Another is to provide a new property on dfdl:defineFormat, which says this dfdl:defineFormat is the default for all top-level objects in the xsd. Any top-level object that remained silent as to its dfdl:ref would get the default applied. I'm not sure whether this makes the model too opaque though. No more so than the existing scoping rules, I suspect. Any other opinions or suggestions welcome. Regards Steve Hanson Programming Model Architect WebSphere Message Brokers Hursley, UK Internet: smh@uk.ibm.com Phone (+44)/(0) 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