[DFDL-WG] Action 086 Nils and Default processing (Discriminators and occursCount)

Stephanie Fetzer sfetzer at us.ibm.com
Wed Jun 2 07:36:46 CDT 2010


I was asked last meeting to document an example with COBOL ODO to see if 
our expectations that discriminators did not impact defaulting was 
correct.
Through the following example I've convinced myself that although 
discriminators may not be involved with defaults that occursCount should 
be.  The difference is a very fine point on how the rules are expressed. 
Let me step through the example...
 

The little odo copybook looks like so:

XML    01  ODO.
XML        10  DEPOSITS.
               20 DEPOSIT-COUNT                 PIC 9(5).
               20 DEPOSITA OCCURS 0 TO 9999 TIMES DEPENDING
                  ON DEPOSIT-COUNT              PIC X(10).

 
 
example data could look like:


00003111111111122222222223333333333
|   |         |         |         |
CORE-FUND-COUNT         |         |
     |        |         |         |
   CORE-FUND[1]         |         |
                        |         |
             CORE-FUND[2]         |
                                  |
                       CORE-FUND[3]
 
 
       -w .\dpa\fls\cob\dpaflscob2.tdf -t 
*************************************************************
*Test Case: dpaflscob_01
*************************************************************
<Infoset xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance">
  <ODO>
    <DEPOSITS>
      <DEPOSIT-COUNT xsi:type="xs:integer">3</DEPOSIT-COUNT>
      <DEPOSITA>1111111111</DEPOSITA>
      <DEPOSITA>2222222222</DEPOSITA>
      <DEPOSITA>3333333333</DEPOSITA>
    </DEPOSITS>
  </ODO>
</Infoset> 
 
The question that we are trying to answer is 'is a discriminator used in 
establishing existence'.  In other words, does it make us
create something that we would otherwise not create in the infoset or in 
the output datastream?  Or - will defaulting take place?

If we look at this as being modelled in DFDL we could model this in 
several ways...one is the way of WTX with discriminators and another way 
is using occursCount:
a la WTX:

<xs:element name="ODO" dfdl:lengthKind="implicit">
    <xs:complexType>
        <xs:sequence dfdl:sequenceKind="ordered">
            <xs:element name="DEPOSITS" dfdl:lengthKind="implicit">
                <xs:complexType>
                    <xs:sequence dfdl:sequenceKind="ordered">
                        <xs:element name="DEPOSIT-COUNT" type="Cobol_9" 
dfdl:length="5"></xs:element>
                        <xs:element name="DEPOSITA" minOccurs="1" 
maxOccurs="unbounded" type="Cobol_X" dfdl:length="10" default="XXXXXXXXXX"
>
                            <xs:annotation>
                                <xs:documentation>Beginning of 
Hierarchical Transaction</xs:documentation>
                                    <xs:appinfo source="
http://www.ogf.org/dfdl/">
                                        <dfdl:discriminator test="{ 
dfdl:count(/ODO/DEPOSITS/DEPOSITA) le /ODO/DEPOSITS/DEPOSIT-COUNT}"/>
                                    </xs:appinfo>
                            </xs:annotation>
                        </xs:element>
                    </xs:sequence>
                </xs:complexType>
            </xs:element>
        </xs:sequence>
    </xs:complexType>
</xs:element> 

The other way would be to use an OccursCount
      <xs:element name="DEPOSITA" minOccurs="1" 
                  maxOccurs="unbounded" type="Cobol_X" 
                  dfdl:length="10" default="XXXXXXXXXX"
                  dfdl:occursCountKind="expression"
                  dfdl:occurCount= "{/ODO/DEPOSITS/DEPOSIT-COUNT}" />
 
The difference in these approaches is that the model with occursCount is 
expressed as a fixed point wheras the model with the discriminator
is a moving point using 'less than or equals'.  I'm expecting that the 
occursCount logic when implemented incorporates
this concept when parsing/unparsing. When I must have three of something 
then the second occur of it is VALID for it
is less than the maximum.  I don't think that we could expect that concept 
to be in the discriminator implementation.  This wording seems trivial but 
it impacts my expectations for default (not sure if rightly so!)

____________________________________

So parsing with the discriminator version.  If my datastream was missing 
the third occur of DEPOSITA, would we expect
a DEFAULT to be applied?   Would discriminator versus occursCount make a 
difference?

Input datastream:   0000311111111112222222222

<Infoset xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance">
  <ODO>
    <DEPOSITS>
      <DEPOSIT-COUNT xsi:type="xs:integer">3</DEPOSIT-COUNT>
      <DEPOSITA>1111111111</DEPOSITA>
      <DEPOSITA>2222222222</DEPOSITA>
    </DEPOSITS>
  </ODO>
</Infoset>

OR

<Infoset xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance">
  <ODO>
    <DEPOSITS>
      <DEPOSIT-COUNT xsi:type="xs:integer">3</DEPOSIT-COUNT>
      <DEPOSITA>1111111111</DEPOSITA>
      <DEPOSITA>2222222222</DEPOSITA>
      <DEPOSITA>XXXXXXXXXX</DEPOSITA>
    </DEPOSITS>
  </ODO>
  </Infoset> 
 
  In this case I would expect the discriminator to create the first 
infoset (sans the default) but the occursCount to create
  the second infoSet with the default. The reason being that the 
discriminator is expressly written as 'less than or equal'
  but the occursCount (even though it acts as le while processing) is 
expressed as a finite number,  But this is a very slight
  distinction.
 
  I've come to the reverse on unparsing...I contend that we consider what 
the following infoset yields:
 
  <Infoset xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="
http://www.w3.org/2001/XMLSchema-instance">
  <ODO>
    <DEPOSITS>
      <DEPOSIT-COUNT xsi:type="xs:integer">3</DEPOSIT-COUNT>
      <DEPOSITA>1111111111</DEPOSITA>
      <DEPOSITA>2222222222</DEPOSITA>
    </DEPOSITS>
  </ODO>
</Infoset>
 
datastream:   0000311111111112222222222XXXXXXXXXX
 
  or
datastream:   0000311111111112222222222

My gut reaction is the first (with defaults) for occursCount and the 
second sans default for the discriminator

I'm hoping there are lots of comments! If there is a simpler way to look 
at this I've missed it thus far  - so please correct me.

Stephanie Fetzer
WebSphere Common Transformation
Industry Packs - Software Engineer




From:
Alan Powell <alan_powell at uk.ibm.com>
To:
dfdl-wg at ogf.org
Date:
06/02/2010 06:22 AM
Subject:
[DFDL-WG] Fw:  Fw: Action 086 Nils and Default processing
Sent by:
dfdl-wg-bounces at ogf.org




I have updated based on last weeks call 


  
Regards 
  
Alan Powell 
  
Development - MQSeries, Message Broker, ESB 
IBM Software Group, Application and Integration Middleware Software 
------------------------------------------------------------------------------------------------------------------------------------------- 

IBM 
MP211, Hursley Park 
Hursley, SO21 2JN 
United Kingdom 
Phone: +44-1962-815073 
e-mail: alan_powell at uk.ibm.com


----- Forwarded by Alan Powell/UK/IBM on 02/06/2010 11:20 ----- 
From: 
Alan Powell/UK/IBM at IBMGB 
To: 
dfdl-wg at ogf.org 
Date: 
25/05/2010 17:27 
Subject: 
[DFDL-WG] Fw: Action 086 Nils and Default processing




All 

I have added unparsing and corrected some of the existing information in 
this latest version. 


  

I did attempt to write out the dfdl:nilValueDelimiterPolicy and 
dfdl:emptyValueDelimiterPolicy options in full but it became unreadable 
hence the 'as controlled by' short cut. 
  
Links still don't work 
Regards 
  
Alan Powell 
  
Development - MQSeries, Message Broker, ESB 
IBM Software Group, Application and Integration Middleware Software 
------------------------------------------------------------------------------------------------------------------------------------------- 

IBM 
MP211, Hursley Park 
Hursley, SO21 2JN 
United Kingdom 
Phone: +44-1962-815073 
e-mail: alan_powell at uk.ibm.com


----- Forwarded by Alan Powell/UK/IBM on 25/05/2010 17:22 ----- 
From: 
Alan Powell/UK/IBM 
To: 
dfdl-wg at ogf.org 
Date: 
13/05/2010 17:28 
Subject: 
Action 086 Nils and Default processing




All 

Attached is an updated version of the nils and defaults sections of the 
specification. I have only completed the parsing section so far which you 
should be able to review while I am on vacation. If someone would like to 
add the unparsing section that would be great. 


  
Note that the cross references are not correct.   
Regards 
  
Alan Powell 
  
Development - MQSeries, Message Broker, ESB 
IBM Software Group, Application and Integration Middleware Software 
------------------------------------------------------------------------------------------------------------------------------------------- 

IBM 
MP211, Hursley Park 
Hursley, SO21 2JN 
United Kingdom 
Phone: +44-1962-815073 
e-mail: alan_powell at uk.ibm.com


  

  



  

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 




  


  

#### dfdl-nils-defaults v2.doc moved to MyAttachments Repository V3.8 (
Link) on 23 May 2010 by Alan Powell. 

  

  



  

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 




  



--
dfdl-wg mailing list
dfdl-wg at ogf.org
http://www.ogf.org/mailman/listinfo/dfdl-wg 

#### dfdl-nils-defaults v3.doc moved to MyAttachments Repository V3.8 (
Link) on 01 June 2010 by Alan Powell. 





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 





[attachment "dfdl-nils-defaults v4.doc" deleted by Stephanie 
Fetzer/Charlotte/IBM] --
  dfdl-wg mailing list
  dfdl-wg at ogf.org
  http://www.ogf.org/mailman/listinfo/dfdl-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20100602/3abe479e/attachment-0001.html 


More information about the dfdl-wg mailing list