I've thought of a further scenario where scoping at the complex type/model group level is problematic. Take a C structure. A complex type might consist of some fixed length fields and some null terminated strings. If there was no scoping then I would specify a terminator for my strings and a length for the other fields. We would also have a precedent rule that stated which was used first if both were present (or we give an error). Because all my terminators are clearly hex zero, I factor that out by setting the terminator on the complex type only. How does that fit with my precedent rules - everything now has a terminator 'set'? What if I want to factor out both a common length and a terminator? We either have to create a complicated set of precedent rules, or provide additional element properties that say 'property x value is given by parent' (yuk) or we limit the properties that can be scoped to avoid such clashes. I also think that we are using scoping at type/group level as a substitute for defining a simple type that carried those dfdl properties (which we have already discounted as bad because of type explosion and schema modification issues). So we are perhaps solving the problem in an unnatural way. The more I think about this, the more I think that 1.0 should not provide scoping at the type/group level, but make sure that we don't preclude its use in the future. At the end of the day, providing scoping does not allow dfdl to describe any more documents. I think we should concentrate on getting the list of properties complete, and establishing the parser behaviour when using those properties. (Don't underestimate how long the latter task will take - I'll provide some examples at the F2F). Regards, Steve Steve Hanson WebSphere Business Integration Brokers, IBM Hursley, England Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 28/04/2005 10:38 ----- Steve Hanson/UK/IBM To 27/04/2005 12:48 DFDL Working Group cc Subject Review of Mike's 'DFDL A Proposal' working draft 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