I am not opposed to the DFDL Lite intellectual approach. I think this may be very fruitful.

However, I want to clarify that IBM really wants, eventually, a standard for pretty much all this functionality including all the knarly little detailed properties, and accurate descriptions of their semantics.  

After all we already have about 6 such non-standard systems, perhaps more, any one of which is likely to be more powerful than a DFDL-Lite subset. For us to justify investing in DFDL implementations we need to be able to subsume the functionality of the internal implementations and move toward a standard. This is the way this saves us money and adds value for our customers.

That said, if this approach of DFDL-lite first makes our likelyhood of overall success larger then this approach is fine.

To me this DFDL-lite concept is really about trying to make modular what is currently monolithic. We shouldn't assume the DFDL v1.0 recommendation will consist of only the "lite" or "core" module.

Key to this is the work on how to express complex behaviors like group separation in a compact and modular fashion sort of like the current conversions stuff for the basic types. If we get that figured out we'll be able to take big complex areas like all the choice and uncertainty stuff, or all the tagged initator complexity, and make it modular.

Mike Beckerle
STSM, Architect, Scalable Computing
IBM Software Group
Information Integration Solutions
Westborough, MA 01581
voice and FAX 508-599-7148
home/mobile office 508-915-4795


"Westhead, Martin \(Martin\)" <westhead@avaya.com>
Sent by: owner-dfdl-wg@ggf.org

07/19/2006 01:54 PM

To
<dfdl-wg@ggf.org>
cc
Subject
[dfdl-wg] DFDL Lite





Hi Folks,
 
Today’s discussion really had me wondering about the size of the thing that we are creating. We are probably looking at a complete spec that is over 200 pages. I feel reasonably strongly that this is too unwieldy. I don’t think that we have the editorial resource to effectively bug-check the document and aside from IBM it is difficult to imagine that there are many groups with the resource to implement it.
 
At the end of today’s call we started discussing features of XML Schema that we might drop from the first release and my attitude to the discussion was one of resistance. Do we really need to drop attributes? Doesn’t the choices document we have pretty much handle wildcards.
 
We are agreed that the property set should be defined with optional libraries around a small, but extensible core. I suggested today that we take the same approach to the whole language.
 
What if were to focus on defining for our initial release a DFDL Lite and look for a minimal set of properties and XML Schema mechanisms that would be useful. Make it as simple and implementable as possible with a minimal of XML Schema and a minimal set of properties. And define it in such a way that we can add the rest of the material as modular supplements (ideally without having to go back and change the existing semantics).
 
There was reasonable support for this approach from those that remained on the call today. I wanted to float it to the group…thoughts anyone?
 
Thanks,
 
Martin