I tend to trust your instincts about things Steve, I would summarize it as this: regardless of how people think nulls *should* work, in XSD nillables are orthogonal to value and whether or not this matches people's past experience we should support it if we're going to overload nillable at all. To me this reasoning is pretty compelling, so I withdraw my suggestion (the "either nillable or default value but not both" idea). ...mikeb Steve Hanson <smh@uk.ibm.com> 12/06/2007 04:59 AM To Mike Beckerle/Worcester/IBM@IBMUS cc dfdl-wg@ogf.org, dfdl-wg-bounces@ogf.org Subject Re: [DFDL-WG] OGF DFDL WG minutes 2007-12-05 call Unfortunately I have been roped into something else which will likely occupy me full time until middle of next week, so I can't look at the defaults/nulls issue in detail right now. But my first reaction to the proposal below is that elements should be allowed to have both null and default values. They are separate concepts in XML Schema, so why are we making the DFDL logical model different? IMHO subtle differences like this cause more issues with customers than the odd extra DFDL property. The DFDL subset of XML Schema should be just that - a subset. For those features of XML Schema that we do support, the rules should be the same. Regards, Steve Steve Hanson WebSphere Message Brokers Hursley, UK Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 Mike Beckerle <beckerle@us.ibm.com> Sent by: dfdl-wg-bounces@ogf.org 05/12/2007 23:21 To dfdl-wg@ogf.org cc Subject [DFDL-WG] OGF DFDL WG minutes 2007-12-05 call OGF DFDL WG minutes 2007-12-05 call Suman Kalia, Simon Parker, Alan Powell, Mike Beckerle (who else? - was someone else on also) We discussed Output issues in the DFDL expression language: E.g.., an outputValueCalc for a field in the header of a data stream may contain information that requires you to know the rep, or length of the rep, of the whole data item. We concluded that this kind of thing can't be ruled out. Some formats just require buffering and are not streamable; however, implementations can vary on just how large a data item they're able to cope with here. Expression language section will include a subsection highlighting this issue and that implementations can vary here. Alan will update his expression language proposal and include this. Also suggested was a path length-from-to function that takes 2 path expressions and gives you the size of the represntation between them. (start of first, to last bit before start of 2nd). (I don't think we discussed a clear use case motivating this, but there may be one. We did discuss applications trying to fit data into limited size boxes, but the use case is not clear. Also note that all representation lengths are subject to change due to different starting alignments.) Nillable and Default: We also discussed the interaction of nillable and having a default. The sense of the group on the call is that we can restrict these so that if something is nillable it cannot also have a default value, and that the behavior of DFDL on output for a required element that is nillable but not in the logical data, is to create a null value. Everyone agreed that there is no need for a property useNullValueForDefault because this should always be the behavior. Mike will forward a proposal. ...mikeb Mike Beckerle STSM, Architect, Scalable Computing IBM Software Group Information Platform and Solutions Westborough, MA 01581 direct: voice and FAX 508-599-7148 assistant: Pam Riordan priordan@us.ibm.com 508-599-7046 -- dfdl-wg mailing list dfdl-wg@ogf.org http://www.ogf.org/mailman/listinfo/dfdl-wg Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU