Hi John

DFDL does not support regex in initiators, but that's not a problem as I think the best way to model this is using discriminators.

Try a model that looks like this, where (s) means xs:sequence and (c) means xs:choice. I've assumed that there could be several records following CONTROLRECORD, of varying types.

Data (s)
Header (s) (1:1)
Body (s) (0:unbounded)
Control (s) (1:1)
Record (c) (0:unbounded)
Type1 (s) (1:1)
Type2 (s) (1:1)
...
TypeN (s) (1:1)
Trailer (s) (1:1)

In each record, model the prefix number as an integer element and the record type as a string element.

Use a discriminator on the record type of Control and each Type1, Type2 etc, that checks the value is the one expected, eg:

<dfdl:discriminator test="{. eq 'CONTROLRECORD'} />
<dfdl:discriminator test="{. eq 'RECORDTYPE1'} />

Here's how this works, using your data as an example:

- Parser parses Header - success
- Parser goes into Body 1
- Parser parses Control
- Discriminator is true - success - we are in Body 1
- Parser goes into Record 1
- Parser assumes Type1 and parses it
- Discriminator is true - success - we are in Record 1
- Parser goes into Record 2
- Parser assumes Type 1 and parses it
- Discriminator is false (because record type is 'CONTROLRECORD') - parser backtracks
- Parser assumes Type 2 and parses it
- Discriminator is false (because record type is 'CONTROLRECORD') - parser backtracks
- <repeat until all branches tried>
- Parser can't match any branch of the choice so concludes that there is no Record 2
- Parser goes into Body 2
- Parser parses Control
- Discriminator is true - success - we are in Body 2
- Parser goes into Record 1
- Parser assumes Type1 and parses it
- Discriminator is true - success - we are in Record 1
- Parser goes into Record 2
- Parser assumes Type1 and parses it
- Discriminator is false (because record type is 'CONTROLRECORD') - parser backtracks
- Parser assumes Type 2 and parses it
- Discriminator is false (because record type is 'CONTROLRECORD') - parser backtracks
- <repeat until all branches tried>
- Parser can't match any branch of the choice so concludes that there is no Record 2
- Parser goes into Body 3
- Parser parses Control
- Discriminator is false (because record type is 'TRAILER') - parser backtracks
- Parser concludes that there is no Body 3
- Parser parses Trailer - success

The NACHA schemas on GitHub follow a similar style to your example. https://github.com/DFDLSchemas/NACHA

Regards

Steve Hanson
Architect, IBM DFDL
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848

From: John Coutinh <john.coutinh@gmail.com>
To: dfdl-wg@ogf.org,
Date: 25/03/2014 02:47
Subject: [DFDL-WG] Initiator with leading variable text
Sent by: dfdl-wg-bounces@ogf.org

Hi All,
I have the following data to parse.

0000|HEADER|value1|value2|value3
0001|CONTROLRECORD|value1|value2|value3
0001|RECORDTYPE1|value101|value101
0002|CONTROLRECORD|value10|value20|value30
0002|RECORDTYPE1|value1010|value1010
0000|TRAILER|value1|value2|value3

The header and trailer are always prefixed with '0000'. I am having trouble with the CONTROLRECORD.
The number '0001' before '|CONTROLRECORD|' applies to following record types until the next number|CONTROLRECORD|.
Can an initiator include a regular expression as part of it's text. If however possible, could an example be provided.
I tried using setVariable based on the number with no success.

Any ideas would be appreciated.
Thanks
John-- dfdl-wg mailing list dfdl-wg@ogf.org https://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