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

[Steve Hanson]

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