Fw: Nulls and Defaults

3 Apr 2008

      I have made the changes discussed yesterday plus the following

added "useNilForDefault is specified" to the definition of  "has default 
value specified? in 13.9
Changed null to nil, nullable to nillable etc except for 
LengthKing=NullTerminated. Agree?

I am concerned about one of the changes

nilIndicatorPath
Path Expression
Path to a logical Boolean field which indicates if this element is null.
For nullKind='nullIndicator'., a path expression referencing another 
element that must be of type Boolean which indicates if this element is 
null. On input, the element value is null if the provided value is true.
When null, on input the element is parsed as normal. If the element length 
is known then the value is skipped otherwise the value must be scannable. 
When null, on output the value is set based on fillByte or padCharacter 
properties and the referenced value set to true.
If non-null then the element is parsed or output normally and the 
referenced value set to false.
Annotation: dfdl:element (all simple types)

By setting the referenced nil indicator we have made it 
impossible/difficult  to implement a streaming unparser. I'm not sure that 
is a good idea.

Also unless we relax the expression rules the indicator bit must be before 
the element.

Please review sections 13.8-13.10

Alan Powell

 MP 211, IBM UK Labs, Hursley,  Winchester, SO21 2JN, England
 Notes Id: Alan Powell/UK/IBM     email: alan_powell@uk.ibm.com 
 Tel: +44 (0)1962 815073                  Fax: +44 (0)1962 816898

----- Forwarded by Alan Powell/UK/IBM on 03/04/2008 12:20 -----

From:
Alan Powell/UK/IBM
To:
Steve Hanson/UK/IBM@IBMGB, "Mike Beckerle" <mbeckerle@OCO-INC.COM>
Date:
01/04/2008 18:35
Subject:
Re: Fw: Nulls and Defaults (was  [DFDL-WG] OGF DFDL WG minutes 2007-12-05 
call)

Steve, Mike

I have finally got around to finishing this off and it turned out to be a 
lot more work than I expected as the default and nulls information as all 
in the wrong places.

Changes

13.8 Properties for Nullable Elements

Updated as requested.
nullKind=xpath changed to nullIndicator as it was xpath is also used in 
nullValue so it was confusing.

13.9    Properties for Default Value Control

Moved from  most of 17.1.1.1 and 17.2 so is now the main description of 
defaults. 

13.10   Nulls, Defaults, and Initiators

Moved from 14.2.1
Updated as requested

17.1.1.1        Repeating and Variable-Occurrence Items and Default Values
Remainder of discussion of variable occurrences.

Outstanding issues

5) Is the list style syntax for dfdl:nullValues acceptable? 
Yes because you can use <dfdl:property name=?nullValues?>?? ?null? 
?NULL?</dfdl:property> 
So what is the syntax and it has to include expressions.

7) Consistent use of nil versus null.   
      => I'm wondering that we should standardise on nil to match xsd ? 
(standardize on nil, not null). 
Does everyone agree to this as it is a significant change to the 
document.?

9)

nullIndicatorPath
Expression
Used when nullKind='nullIndicator'. A path expression referencing another 
element that provides the logical value to compare with nullValues On 
input, the element value is null if the provided value matches in 
nullValues.
When null, If the element is fixed length then it will be skipped on 
input, filled with (TBD: fillbyte?) on output..
Is this correct??? Should it set element to Null? 
When null If the element is variable length with minimum length > 0, then 
a minimum length item will be skipped over, or on output filled (TBD with 
fillbyte?). 
When null If the element is variable length with minimum length 0, then a 
length zero object is expected on input, and a length 0 object will be 
generated on output.
If non-null then the element is parsed or output normally.
Annotation: dfdl:element (all simple types)

10)

useNullValueForDefault
Boolean 
Ignored on input.
IS this correct. Shouldn't it set null if element is required?
On output, if an element is not in the logical model, but it is required, 
the element is nillable, and has dfdl:useNullValueForDefault="true", then 
the logical value is defaulted to null. 
Annotation: dfdl:element (all simple types)

Can you make sure you are happy with the changes.

[attachment "ogf-dfdl-v1.0-Core-032.doc" deleted by Alan Powell/UK/IBM] 

Alan Powell

 MP 211, IBM UK Labs, Hursley,  Winchester, SO21 2JN, England
 Notes Id: Alan Powell/UK/IBM     email: alan_powell@uk.ibm.com 
 Tel: +44 (0)1962 815073                  Fax: +44 (0)1962 816898

From:
Alan Powell/UK/IBM
To:
Steve Hanson/UK/IBM@IBMGB
Cc:
Alan Powell/UK/IBM
Date:
07/02/2008 17:13
Subject:
Re: Fw: Nulls and Defaults (was  [DFDL-WG] OGF DFDL WG minutes 2007-12-05 
call)

Steve

I have done most of this update. See below
Will co,plete in next rev

Alan Powell

 MP 211, IBM UK Labs, Hursley,  Winchester, SO21 2JN, England
 Notes Id: Alan Powell/UK/IBM     email: alan_powell@uk.ibm.com 
 Tel: +44 (0)1962 815073                  Fax: +44 (0)1962 816898

Steve Hanson/UK/IBM 
06/02/2008 09:26

To
Alan Powell/UK/IBM
cc

Subject
Fw: Nulls and Defaults (was  [DFDL-WG] OGF DFDL WG minutes 2007-12-05 
call)

Hi Alan - nulls and defaults changes below.

Regards, Steve

Steve Hanson
WebSphere Message Brokers
Hursley, UK
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848
----- Forwarded by Steve Hanson/UK/IBM on 06/02/2008 09:25 -----

"Mike Beckerle" <mbeckerle@OCO-INC.COM> 
05/02/2008 21:17

To
Steve Hanson/UK/IBM@IBMGB
cc

Subject
RE: Nulls and Defaults (was  [DFDL-WG] OGF DFDL WG minutes 2007-12-05 
call)

Looks good.

From: Steve Hanson [mailto:smh@uk.ibm.com] 
Sent: Tuesday, February 05, 2008 12:22 PM
To: Mike Beckerle
Subject: RE: Nulls and Defaults (was [DFDL-WG] OGF DFDL WG minutes 
2007-12-05 call)

Hi Mike 

Looks good, small corrections in blue. With those made we can send to Alan 
I think. 

Regards, Steve

Steve Hanson
WebSphere Message Brokers
Hursley, UK
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848 

"Mike Beckerle" <mbeckerle@OCO-INC.COM> 
05/02/2008 14:57 

To
Steve Hanson/UK/IBM@IBMGB 
cc

Subject
RE: Nulls and Defaults (was  [DFDL-WG] OGF DFDL WG minutes 2007-12-05 
call)

Issues this raises 
1) How can you represent empty string as 
a) a null value? 
b) a default value (not sure you can)? 

1        Proposal: Input Defaulting for Empty Strings 
This is a corner case for strings. If an element is of type string, and 
has a default value specified, it is not clear whether the empty string 
should be an allowed value or if the empty string, when found in the 
representation, should trigger use of the default value instead. 
The following makes this corner case unambiguous: 
Type string with minLength of zero and default value are incompatible. It 
is a schema definition error if a variable length string where zero length 
is valid also has a default value specified.
Not yet added. Wasn't sure where this should go as the Nulls,Default info 
is scattered around
This eliminates complexities around the issue of ?empty? content. Empty 
content always triggers use of the default value. If the type is string 
and empty string is a legal value then there cannot be a default value. 
We also need the same for null values 
Type string with minLength of zero and nillable with empty string as one 
of the dfdl:nullValues are incompatible. It is a schema definition error 
if a variable length string where zero length is valid also is nillable 
and has a null value of empty string specified.
Not yet added. Wasn't sure where this should go as the Nulls,Default info 
is scattered around
2) Why are nullIndicatorPath and nullIndicatorIndex separate properties? 
Convenience. So you can scope the nullIndicatorPath, and have local 
indices. 

3) What does 'missing' mean when initiators are involved? 
      => Covered by extra properties dfdl:nullValueInitiatorPolicy & 
dfdl:defaultValueInitiatorPolicy, as given by tables in 14.2.1.1 and 
14.2.1.2 
      => I think the bottom row of the table in 14.2.1.2 is incorrect - in 
the infoset, empty string and missing element are two distinct cases - how 
do/did we resolve this? 
Changes to this definition: 

defaultValueInitiatorPolicy 
Enum 
Valid values are 'required' or 'prohibited' 
Ignored unless dfdl:initiator is specified and is not "" (empty string). 
Ignored unless the element declaration has a default attribute specified. 
'required' indicates that the dfdl:initiator followed by empty content is 
the required syntax to indicate that a default value will be used. 
'prohibited' indicates that empty content triggers the use of a default 
value, and the presence of an initiator implies that a non-default value 
representation must follow. 
?prohibited? implies an ordered sequence. Use of 
defaultValueInitiatorPolicy=?prohibited? in an initiated element of an 
unordered group is a schema definition error. 
This property applies only on input. (On output, for a required output an 
initiator is always output regardless of the default value.)

Added

1.1.1.1      Initiators and Output 
This table describes the output direction logic for an initiated element 
that is a required element. We assume here that dfdl:initiator is 
specified and not equal to the empty string. 

Logical Value
nullValueInitiatorPolicy

useNullValueForDefault
initiator region contains
content region contains
nil 
prohibited 

don't care 

nothing 
representation of nil based on nullKind, nullValues, etc. 
required 
initiator string 
"" (empty string) 
Note that this implies that the element type is xs:string and no default 
value can be specified. 
don't care 
initiator string 
empty string 
a non-nil non-empty-string value 
don't care 
initiator string 

The representation of the logical value 
Not supplied 
(element is not nillable) 
Don?t care 
Don?t care 
Initiator string 
The representation of the default value. 
(No default value implies processing error.) 
Not supplied 
(nillable) 
Prohibited 
True 
Nothing 
Representation of nil basd on nullKind, nullValues, etc. 
Required 
Initiator string 
Don?t care 
False 
Initiator String 
The representation of the default value. 
(No default value implies processing error.)
  Added but had trould with table format as couldn't copy/paste.

4) What controls null versus default for a missing element on output? 
      => Extra property dfdl:useNullValueForDefault 
See above. 

5) Is the list style syntax for dfdl:nullValues acceptable? 
Yes because you can use <dfdl:property name=?nullValues?>?? ?null? 
?NULL?</dfdl:property> 
Which avoids quoting hell. 
(there?s still some issue of list-valued expressions.) 

6) Error cases - need to enumerate these 
      => Input. Required element missing and no default value. 
(processing error) 

      => Output. Required element missing and no default value or null 
value. 
(processing error) 

      => Output. Element is null  and is not nillable. 
(processing error at least. It may be possible for some implementations to 
detect this error sooner.) 

      => ? 

7) Consistent use of nil versus null.   
      => I'm wondering that we should standardise on nil to match xsd ? 
(standardize on nil, not null). 

Regards, Steve

Steve Hanson
WebSphere Message Brokers
Hursley, UK
Internet: smh@uk.ibm.com
Phone (+44)/(0) 1962-815848 
----- Forwarded by Steve Hanson/UK/IBM on 04/02/2008 16:06 ----- 
Hi Mike 

In preparation for our discussion on nulls and defaults tomorrow..... 

First of all I'd like to restate what I see as the requirements: 

Uncontentious core properties 
xs:default 
xs:fixed 
dfdl:nullKind 
dfdl:nullValues 
dfdl:nullIndicatorPath 
dfdl:nullIndicatorIndex 

Assumptions 
- 'Required' below is as defined in section 17.1.1.1. 
- The term 'default value' below actually means 'xs:default or xs:fixed' 
- Both default values and null values only apply to simple elements 

Input 
- If a required element is missing from the data stream and it has a 
default value, that will be used as the infoset value of the element 
- If an element is nillable and has a value in the data stream which 
matches one of a list of null values, the infoset value of the element 
will be the special value null 

Output 
- If a required element is missing from the infoset and it has a default 
value, optionally that will be used as the infoset value of the element 
- If a required element is missing from the infoset, optionally the 
special value null  will be used as the infoset value of the element 
- If an element is nillable and has an infoset value null , the value in 
the data stream will be the first of the list of null values

Issues this raises 
1) How can you represent empty string as 
a) a null value? 
b) a default value (not sure you can)? 

2) Why are nullIndicatorPath and nullIndicatorIndex separate properties? 

3) What does 'missing' mean when initiators are involved? 
        => Covered by extra properties dfdl:nullValueInitiatorPolicy & 
dfdl:defaultValueInitiatorPolicy, as given by tables in 14.2.1.1 and 
14.2.1.2 
        => I think the bottom row of the table in 14.2.1.2 is incorrect - 
in the infoset, empty string and missing element are two distinct cases - 
how do/did we resolve this? 

4) What controls null versus default for a missing element on output? 
        => Extra property dfdl:useNullValueForDefault 

5) Is the list style syntax for dfdl:nullValues acceptable? 

6) Error cases - need to enumerate these 
        => Input. Required element missing and no default value. 
        => Output. Required element missing and no default value or null 
value. 
        => Output. Element is null  and is not nillable. 
        => ? 

7) Consistent use of nil versus null.   
        => I'm wondering that we should standardise on nil to match xsd ? 

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> 
06/12/2007 13:50 

To
Steve Hanson/UK/IBM@IBMGB 
cc
dfdl-wg@ogf.org, dfdl-wg-bounces@ogf.org 
Subject
Re: [DFDL-WG] OGF DFDL WG minutes 2007-12-05 call

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 

Alan Powell

Steve Hanson

Mike Beckerle

Steve Hanson

Mike Beckerle

Steve Hanson

tags

participants (3)