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