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