Here's a quick review prior to the discussion on today's call. I went through it all bar the appendices, I'm happy to defer discussion of the non-scope points to the F2F. Section 1 - Arrays - does not include unbounded maxOccurs (-1) - is that intentional ? Section 3 <See separate mail on the schema subset> Section 4 - Example shows only one dataformat appinfo per schema object. I think we need multiple (named) DFDL descriptions per schema. Example - I want to read in a COBOL structure and output it another non-XML form, eg, in CSV format. We do see this in the messaging world. One issue with this suggestion is where includes/imports are involved - clearly the names must match up. I guess for 1.0 we could go with a single unnamed DFDL description per schema, that would not preclude later addition of named DFDL descriptions. Section 5.1 - No issue with the concept, but the name 'local element scope' is misleading. On first read I assumed this applied to schema 'local elements' and not to 'global elements'. 'Local object scope' might be better? Section 6.1 - Not convinced that the benefit of scopes outweighs the complexity disadvantage. DFDL would work quite happily for the vast majority of cases with a set of properties defined per schema object, each property having a DFDL-defined default that was overridable on a per schema basis. I think we should do this for 1.0 and see whether we get a requirement for scoping from initial users. This simple scheme I suggest does not preclude introducing scoping at a later date. - If you select an object randomly in a schema it should be easy to deduce the values in force for a given property. With scoping it is not easy, as it is containment dependent. - An example of why scoping can be confusing. I have a complex type. The type has a byte alignment property of 'word', being a scoped property meaning that all child elements take a byte alignment of 'word' unless they overridde it. But it could just as easily be interpreted as meaning that an element of that complex type should be 'word' aligned. (Though I guess scoping could handle this by having a <dfdl:scope> sub-element specifically for scoped properties?). - If you recall I sent an e-mail to one of IBM's XML Schema WG reps, asking whether they had considered using property scoping. The answer was they didn't think schema would ever adopt this, but I can't recall the precise reasoning. Section 6.2 - I guess this list will grow to include xsd:all groups, element references. attribute references and local/global attributes, as discussed - We should explicitly say that simple types are excluded with reasoning, as discussed in the past. Section 6.3 - Don't understand what 'dynamically included in the definition' means? - Location (1). As hinted above in my 6.1 comment, I see nothing wrong with using a global location to change DFDL property defaults for the scope of the whole schema. This is a very useful facility. - Location (6). I don't think providing global defaults here is a good idea. It sounds ok when the element truly is top level, but what about when it is referenced by an element reference? It makes working out the defaults in force at a given point in the schema very difficult. Section 6.5 - Differing opinion already noted above. Section 6.6 - In my scope-less suggestion, the global properties in an included/imported schema apply to the objects in that schema. So you can still deduce the values in force when a random object is selected. Only wrinkle is xsd:redefine, presumably the including schema properties apply. (I would also suggest that xsd:redefine not be supported for 1.0). Section 8. - Don't understand - can you clarify ? Section 9. - I don't think this is essential for 1.0. Section 10.4 - Yes this is needed. Other examples are EDIFACT, X12 and HL7. Regards, Steve Steve Hanson WebSphere Business Integration Brokers, IBM Hursley, England Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848