[dfdl-wg] Fw: Review of Mike's 'DFDL A Proposal' working draft

[Steve Hanson]

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 at 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 at uk.ibm.com
Phone (+44)/(0) 1962-815848