Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

classic Classic list List threaded Threaded
41 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Tom Fennelly
Yeah... that makes sense to me Bard.  In fact, I seem to remember someone looking for something similar with CSV i.e. wanting the CSVReader to support a record stream that contained multiple record/transaction types.

Lets move this conversation to the dev list if that's OK... please reply there.

What do people think of the following.... I usually like to start with the confg aspects i.e. how would I like to use this, and from what I hear from you guys, sound like we need the reader to support config of multiple fieldsets, as well definition of some form of matching rules e.g.

<fl:reader>
    <fieldsets>
        <fieldset fields="firstName[20]?trim,lastName[20]?trim,gender[6]?trim.upper_case,age[3]?trim,country[2]" matchOn="1-3='Tom',21-29='Fennelly'" />
        <fieldset fields="firstName[10]?trim,lastName[10]?trim,gender[6]?trim.upper_case"                        matchOn="1-4='Bard',11-16='Langoy'" />
    </fieldsets>
</fl:reader>
  
Would something like that work?

T.


Bård Langöy wrote:
Hi,

Yes, I think the best solution would be to extend the fixed length parser. Even though the EDIParser has a way of defining sequences it might not be sufficient for the fixed-length parser. First off the flat-file might need multiple values for matching  a line type... for example it would need the value at position 1-2 and also position 3-12 to decide the type of line/transaction that is being currently processed. Also, the sequence algorithm might be different from the EDIParser. When is it ok to invoke a new event in Smooks ? It might be the end of a transaction that consists of several lines in the input-file. The EDIParser on the opposite invokes a new event at first matching segment. 

I think these things should be considered before extending the EDIParser at least.

Regards,
Bård

-----Ursprungligt meddelande-----
Från: pembertona [[hidden email]] 
Skickat: den 21 december 2009 13:56
Till: [hidden email]
Ämne: Re: [milyn-user] SV: Smooks EDI fixed length question/feature request


Hey guys:

1) First, thanks for the quick replies.

2) to Tom's question... the data I'm dealing with is labeled "EDI", but uses
field length (with fixed and variable length segments) as a core part of the
syntax. To my understanding, EDI itself is not a specification, but a more
general classification of plain-text data transmission methods (which are
usually themselves proprietary specifications) - am I wrong here?

3) It is a nationally-recognized standard (in the US) for reporting
accident/injury information for Workers' Compensation purposes (see:
http://www.iaiabc.org/i4a/pages/index.cfm?pageid=3338) (unfortunately, you
have to be a 'member' to look at the EDI implementation
guide/specification).

4) I tried to attach the following to my original email before it was
approved, but don't think I made it:


"I've looked into the fixed-length cartridge on trunk, but it looks fairly
new and not as feature-rich as the EDI cartridge. So basically, I need the
EDI cartridge, with fixed-length processing at the field level."

It sounds like Bård hit the nail on the head - I'd need to extend the fixed
length cartridge (or EDI cartridge) to build out the functionality I need.

Thoughts?
-AP

  
Reply | Threaded
Open this post in threaded view
|

SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Bård Langöy

Hi again,

 

Yes I really like the matchOn attribute with support for several match alternatives. When I wrote a similar cartridge earlier I separated the field definition and the sequence flow for easier reading. Something like the example below… in the example below you might extract the same information several times like “fullName”.  But it could instead  function like the EdiParser where  the sequence flow is inside the field-structure, but with import support to enable separation of sequence and definition.

 

Just some thoughts J

 

<fl:reader>
    <fields>
        <field name=”nameField” matchOn="1-4='Bard',11-16='Langoy'">
               <unit name=”firstName” startPos=”0” endPos=”20”/>
               <unit name=”lastName” startPos=”21” endPos=”30”/>
               <unit name=”fullName” startPos=”0” endPos=”30”/>
               <unit name=”age” startPos=”31” endPos=”33”/>
        <field>
 
        <field name=”subField” matchOn="1-4='Bard',11-16='Langoy'">
               <unit name=”sub1” startPos=”0” endPos=”20”/>
               <unit name=”sub2” startPos=”21” endPos=”30”/>
        <field>
    </fields>
 
    <sequences>
        …
    </sequences>
</fl:reader>

 

 

Regards,

Bård

 

Från: Tom Fennelly [mailto:[hidden email]]
Skickat: den 22 december 2009 10:33
Till: [hidden email]
Kopia: [hidden email]
Ämne: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

 

Yeah... that makes sense to me Bard.  In fact, I seem to remember someone looking for something similar with CSV i.e. wanting the CSVReader to support a record stream that contained multiple record/transaction types.

Lets move this conversation to the dev list if that's OK... please reply there.

What do people think of the following.... I usually like to start with the confg aspects i.e. how would I like to use this, and from what I hear from you guys, sound like we need the reader to support config of multiple fieldsets, as well definition of some form of matching rules e.g.

<fl:reader>
    <fieldsets>
        <fieldset fields="firstName[20]?trim,lastName[20]?trim,gender[6]?trim.upper_case,age[3]?trim,country[2]" matchOn="1-3='Tom',21-29='Fennelly'" />
        <fieldset fields="firstName[10]?trim,lastName[10]?trim,gender[6]?trim.upper_case"                        matchOn="1-4='Bard',11-16='Langoy'" />
    </fieldsets>
</fl:reader>
  

Would something like that work?

T.


Bård Langöy wrote:

Hi,
 
Yes, I think the best solution would be to extend the fixed length parser. Even though the EDIParser has a way of defining sequences it might not be sufficient for the fixed-length parser. First off the flat-file might need multiple values for matching  a line type... for example it would need the value at position 1-2 and also position 3-12 to decide the type of line/transaction that is being currently processed. Also, the sequence algorithm might be different from the EDIParser. When is it ok to invoke a new event in Smooks ? It might be the end of a transaction that consists of several lines in the input-file. The EDIParser on the opposite invokes a new event at first matching segment. 
 
I think these things should be considered before extending the EDIParser at least.
 
Regards,
Bård
 
-----Ursprungligt meddelande-----
Från: pembertona [[hidden email]] 
Skickat: den 21 december 2009 13:56
Till: [hidden email]
Ämne: Re: [milyn-user] SV: Smooks EDI fixed length question/feature request
 
 
Hey guys:
 
1) First, thanks for the quick replies.
 
2) to Tom's question... the data I'm dealing with is labeled "EDI", but uses
field length (with fixed and variable length segments) as a core part of the
syntax. To my understanding, EDI itself is not a specification, but a more
general classification of plain-text data transmission methods (which are
usually themselves proprietary specifications) - am I wrong here?
 
3) It is a nationally-recognized standard (in the US) for reporting
accident/injury information for Workers' Compensation purposes (see:
http://www.iaiabc.org/i4a/pages/index.cfm?pageid=3338) (unfortunately, you
have to be a 'member' to look at the EDI implementation
guide/specification).
 
4) I tried to attach the following to my original email before it was
approved, but don't think I made it:
 
 
"I've looked into the fixed-length cartridge on trunk, but it looks fairly
new and not as feature-rich as the EDI cartridge. So basically, I need the
EDI cartridge, with fixed-length processing at the field level."
 
It sounds like Bård hit the nail on the head - I'd need to extend the fixed
length cartridge (or EDI cartridge) to build out the functionality I need.
 
Thoughts?
-AP
 
  
Reply | Threaded
Open this post in threaded view
|

Re: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

pembertona
We're definitely on the right track here; to meet the requirements implied by the IAIABC EDI spec, we'd need something like the nested group structure from the EDI cartridge.

In this data structure, a given file interchange (a "transmission") represents the form:

Transmission (1)
    Batch (1..*)
        Header (1)
        Transactions (1..*)
        Trailer (1)
       
So it could be mapped with something like:

<fl:reader>
    <fieldGroup xmltag="Transmission">
        <fieldGroup xmltag="Batch" maxOccurs="-1">
            <fieldset xmltag="Header" matchOn="1-3='HD1'" fields="transactionSetId[3],..."/>
            <fieldGroup xmltag="Transactions">
                <fieldset fields="transactionSetId[3],..."/>
            </fieldGroup>
            <fieldset xmltag="Trailer" matchOn="1-3='TR2'" fields="transactionSetId[3],..."/>           
        </fieldGroup>
    </fieldGroup>
</fl:reader>

Unfortunately, things only get more complicated at the 'transaction' level. There are (at least) 6 different transaction types, with "variable length segments" (eg: fixed length for the field itself, but the field can exist N times).

So, do you guys think this is a reasonable use of the 'group' strategy from other cartridges?

-AP

On Tue, Dec 22, 2009 at 10:32 AM, Bård Langöy <[hidden email]> wrote:

Hi again,

 

Yes I really like the matchOn attribute with support for several match alternatives. When I wrote a similar cartridge earlier I separated the field definition and the sequence flow for easier reading. Something like the example below… in the example below you might extract the same information several times like “fullName”.  But it could instead  function like the EdiParser where  the sequence flow is inside the field-structure, but with import support to enable separation of sequence and definition.

 

Just some thoughts J

 

<fl:reader>
    <fields>
        <field name=”nameField” matchOn="1-4='Bard',11-16='Langoy'">
               <unit name=”firstName” startPos=”0” endPos=”20”/>
               <unit name=”lastName” startPos=”21” endPos=”30”/>
               <unit name=”fullName” startPos=”0” endPos=”30”/>
               <unit name=”age” startPos=”31” endPos=”33”/>
        <field>
 
        <field name=”subField” matchOn="1-4='Bard',11-16='Langoy'">
               <unit name=”sub1” startPos=”0” endPos=”20”/>
               <unit name=”sub2” startPos=”21” endPos=”30”/>
        <field>
    </fields>
 
    <sequences>
        …
    </sequences>
</fl:reader>

 

 

Regards,

Bård

 

Från: Tom Fennelly [mailto:[hidden email]]
Skickat: den 22 december 2009 10:33
Till: [hidden email]
Kopia: [hidden email]
Ämne: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

 

Yeah... that makes sense to me Bard.  In fact, I seem to remember someone looking for something similar with CSV i.e. wanting the CSVReader to support a record stream that contained multiple record/transaction types.

Lets move this conversation to the dev list if that's OK... please reply there.

What do people think of the following.... I usually like to start with the confg aspects i.e. how would I like to use this, and from what I hear from you guys, sound like we need the reader to support config of multiple fieldsets, as well definition of some form of matching rules e.g.

<fl:reader>
    <fieldsets>
        <fieldset fields="firstName[20]?trim,lastName[20]?trim,gender[6]?trim.upper_case,age[3]?trim,country[2]" matchOn="1-3='Tom',21-29='Fennelly'" />
        <fieldset fields="firstName[10]?trim,lastName[10]?trim,gender[6]?trim.upper_case"                        matchOn="1-4='Bard',11-16='Langoy'" />
    </fieldsets>
</fl:reader>
  

Would something like that work?

T.


Bård Langöy wrote:

Hi,
 
Yes, I think the best solution would be to extend the fixed length parser. Even though the EDIParser has a way of defining sequences it might not be sufficient for the fixed-length parser. First off the flat-file might need multiple values for matching  a line type... for example it would need the value at position 1-2 and also position 3-12 to decide the type of line/transaction that is being currently processed. Also, the sequence algorithm might be different from the EDIParser. When is it ok to invoke a new event in Smooks ? It might be the end of a transaction that consists of several lines in the input-file. The EDIParser on the opposite invokes a new event at first matching segment. 
 
I think these things should be considered before extending the EDIParser at least.
 
Regards,
Bård
 
-----Ursprungligt meddelande-----
Från: pembertona [[hidden email]] 
Skickat: den 21 december 2009 13:56
Till: [hidden email]
Ämne: Re: [milyn-user] SV: Smooks EDI fixed length question/feature request
 
 
Hey guys:
 
1) First, thanks for the quick replies.
 
2) to Tom's question... the data I'm dealing with is labeled "EDI", but uses
field length (with fixed and variable length segments) as a core part of the
syntax. To my understanding, EDI itself is not a specification, but a more
general classification of plain-text data transmission methods (which are
usually themselves proprietary specifications) - am I wrong here?
 
3) It is a nationally-recognized standard (in the US) for reporting
accident/injury information for Workers' Compensation purposes (see:
http://www.iaiabc.org/i4a/pages/index.cfm?pageid=3338) (unfortunately, you
have to be a 'member' to look at the EDI implementation
guide/specification).
 
4) I tried to attach the following to my original email before it was
approved, but don't think I made it:
 
 
"I've looked into the fixed-length cartridge on trunk, but it looks fairly
new and not as feature-rich as the EDI cartridge. So basically, I need the
EDI cartridge, with fixed-length processing at the field level."
 
It sounds like Bård hit the nail on the head - I'd need to extend the fixed
length cartridge (or EDI cartridge) to build out the functionality I need.
 
Thoughts?
-AP
 
  



--
Andy Pemberton
www.andypemberton.com
Reply | Threaded
Open this post in threaded view
|

SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Bård Langöy

Hm…

 

I would really like to see the specification for this. Just to better grasp how the sequence flow is implemented. I will look around if I can find an example file or something. Or could you provide us with this Andy ? If the specs were licensed in some way maybe just an example-file will do for now..

 

Regards,

Bård

 

Från: Andy Pemberton [mailto:[hidden email]]
Skickat: den 23 december 2009 05:18
Till: [hidden email]
Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

 

We're definitely on the right track here; to meet the requirements implied by the IAIABC EDI spec, we'd need something like the nested group structure from the EDI cartridge.

In this data structure, a given file interchange (a "transmission") represents the form:

Transmission (1)
    Batch (1..*)
        Header (1)
        Transactions (1..*)
        Trailer (1)
       
So it could be mapped with something like:

<fl:reader>
    <fieldGroup xmltag="Transmission">
        <fieldGroup xmltag="Batch" maxOccurs="-1">
            <fieldset xmltag="Header" matchOn="1-3='HD1'" fields="transactionSetId[3],..."/>
            <fieldGroup xmltag="Transactions">
                <fieldset fields="transactionSetId[3],..."/>
            </fieldGroup>
            <fieldset xmltag="Trailer" matchOn="1-3='TR2'" fields="transactionSetId[3],..."/>           
        </fieldGroup>
    </fieldGroup>
</fl:reader>

Unfortunately, things only get more complicated at the 'transaction' level. There are (at least) 6 different transaction types, with "variable length segments" (eg: fixed length for the field itself, but the field can exist N times).

So, do you guys think this is a reasonable use of the 'group' strategy from other cartridges?

-AP

On Tue, Dec 22, 2009 at 10:32 AM, Bård Langöy <[hidden email]> wrote:

Hi again,

 

Yes I really like the matchOn attribute with support for several match alternatives. When I wrote a similar cartridge earlier I separated the field definition and the sequence flow for easier reading. Something like the example below… in the example below you might extract the same information several times like “fullName”.  But it could instead  function like the EdiParser where  the sequence flow is inside the field-structure, but with import support to enable separation of sequence and definition.

 

Just some thoughts J

 

<fl:reader>
    <fields>
        <field name=”nameField” matchOn="1-4='Bard',11-16='Langoy'">
               <unit name=”firstName” startPos=”0” endPos=”20”/>
               <unit name=”lastName” startPos=”21” endPos=”30”/>
               <unit name=”fullName” startPos=”0” endPos=”30”/>
               <unit name=”age” startPos=”31” endPos=”33”/>
        <field>
 
        <field name=”subField” matchOn="1-4='Bard',11-16='Langoy'">
               <unit name=”sub1” startPos=”0” endPos=”20”/>
               <unit name=”sub2” startPos=”21” endPos=”30”/>
        <field>
    </fields>
 
    <sequences>
        …
    </sequences>
</fl:reader>

 

 

Regards,

Bård

 

Från: Tom Fennelly [mailto:[hidden email]]
Skickat: den 22 december 2009 10:33
Till: [hidden email]
Kopia: [hidden email]
Ämne: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

 

Yeah... that makes sense to me Bard.  In fact, I seem to remember someone looking for something similar with CSV i.e. wanting the CSVReader to support a record stream that contained multiple record/transaction types.

Lets move this conversation to the dev list if that's OK... please reply there.

What do people think of the following.... I usually like to start with the confg aspects i.e. how would I like to use this, and from what I hear from you guys, sound like we need the reader to support config of multiple fieldsets, as well definition of some form of matching rules e.g.

<fl:reader>
    <fieldsets>
        <fieldset fields="firstName[20]?trim,lastName[20]?trim,gender[6]?trim.upper_case,age[3]?trim,country[2]" matchOn="1-3='Tom',21-29='Fennelly'" />
        <fieldset fields="firstName[10]?trim,lastName[10]?trim,gender[6]?trim.upper_case"                        matchOn="1-4='Bard',11-16='Langoy'" />
    </fieldsets>
</fl:reader>
  

Would something like that work?

T.


Bård Langöy wrote:

Hi,
 
Yes, I think the best solution would be to extend the fixed length parser. Even though the EDIParser has a way of defining sequences it might not be sufficient for the fixed-length parser. First off the flat-file might need multiple values for matching  a line type... for example it would need the value at position 1-2 and also position 3-12 to decide the type of line/transaction that is being currently processed. Also, the sequence algorithm might be different from the EDIParser. When is it ok to invoke a new event in Smooks ? It might be the end of a transaction that consists of several lines in the input-file. The EDIParser on the opposite invokes a new event at first matching segment. 
 
I think these things should be considered before extending the EDIParser at least.
 
Regards,
Bård
 
-----Ursprungligt meddelande-----
Från: pembertona [[hidden email]] 
Skickat: den 21 december 2009 13:56
Till: [hidden email]
Ämne: Re: [milyn-user] SV: Smooks EDI fixed length question/feature request
 
 
Hey guys:
 
1) First, thanks for the quick replies.
 
2) to Tom's question... the data I'm dealing with is labeled "EDI", but uses
field length (with fixed and variable length segments) as a core part of the
syntax. To my understanding, EDI itself is not a specification, but a more
general classification of plain-text data transmission methods (which are
usually themselves proprietary specifications) - am I wrong here?
 
3) It is a nationally-recognized standard (in the US) for reporting
accident/injury information for Workers' Compensation purposes (see:
http://www.iaiabc.org/i4a/pages/index.cfm?pageid=3338) (unfortunately, you
have to be a 'member' to look at the EDI implementation
guide/specification).
 
4) I tried to attach the following to my original email before it was
approved, but don't think I made it:
 
 
"I've looked into the fixed-length cartridge on trunk, but it looks fairly
new and not as feature-rich as the EDI cartridge. So basically, I need the
EDI cartridge, with fixed-length processing at the field level."
 
It sounds like Bård hit the nail on the head - I'd need to extend the fixed
length cartridge (or EDI cartridge) to build out the functionality I need.
 
Thoughts?
-AP
 
  




--
Andy Pemberton
www.andypemberton.com

Reply | Threaded
Open this post in threaded view
|

Re: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

pembertona
The implementation guide for the specification itself is licensed; so I've included a sample file.

The file structure looks like:

Header Record
First Report of Injury
First Report of Injury Companion Record
First Report of Injury
First Report of Injury Companion Record
Trailer Record

So it's 1 transmission, with 1 batch of records, 1 header, 4 transactions, and 1 trailer.

-Andy

On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]> wrote:

Hm…

 

I would really like to see the specification for this. Just to better grasp how the sequence flow is implemented. I will look around if I can find an example file or something. Or could you provide us with this Andy ? If the specs were licensed in some way maybe just an example-file will do for now..

 

Regards,

Bård


--
Andy Pemberton
www.andypemberton.com

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

iaiabc-test.edi (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Tom Fennelly
In reply to this post by pembertona
Hmmm.... this all sounds more complex than I was originally thinking Andy :)  Sounds like it has a lot more in common with EDI than CSV.  I think I'd look at extending the whole "delimiter" concept for EDI to include position based delimiters, with the ability to override at the model node level (field, component and sub-component).

So something like this perhaps:
<medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
	<medi:field xmltag="order-id"  matchOn="4-10"/>
	<medi:field xmltag="status-code" matchOn="11='A'"/>
	<medi:field xmltag="net-amount" matchOn="12-22"/>
	<medi:field xmltag="total-amount" matchOn="23-33"/>
	<medi:field xmltag="tax" matchOn="34-44"/>
	<medi:field xmltag="date" matchOn="45-55"/>
</medi:segment>
  



Andy Pemberton wrote:
We're definitely on the right track here; to meet the requirements implied by the IAIABC EDI spec, we'd need something like the nested group structure from the EDI cartridge.

In this data structure, a given file interchange (a "transmission") represents the form:

Transmission (1)
    Batch (1..*)
        Header (1)
        Transactions (1..*)
        Trailer (1)
       
So it could be mapped with something like:

<fl:reader>
    <fieldGroup xmltag="Transmission">
        <fieldGroup xmltag="Batch" maxOccurs="-1">
            <fieldset xmltag="Header" matchOn="1-3='HD1'" fields="transactionSetId[3],..."/>
            <fieldGroup xmltag="Transactions">
                <fieldset fields="transactionSetId[3],..."/>
            </fieldGroup>
            <fieldset xmltag="Trailer" matchOn="1-3='TR2'" fields="transactionSetId[3],..."/>           
        </fieldGroup>
    </fieldGroup>
</fl:reader>

Unfortunately, things only get more complicated at the 'transaction' level. There are (at least) 6 different transaction types, with "variable length segments" (eg: fixed length for the field itself, but the field can exist N times).

So, do you guys think this is a reasonable use of the 'group' strategy from other cartridges?

-AP

On Tue, Dec 22, 2009 at 10:32 AM, Bård Langöy <[hidden email]> wrote:

Hi again,

 

Yes I really like the matchOn attribute with support for several match alternatives. When I wrote a similar cartridge earlier I separated the field definition and the sequence flow for easier reading. Something like the example below… in the example below you might extract the same information several times like “fullName”.  But it could instead  function like the EdiParser where  the sequence flow is inside the field-structure, but with import support to enable separation of sequence and definition.

 

Just some thoughts J

 

<fl:reader>
    <fields>
        <field name=”nameField” matchOn="1-4='Bard',11-16='Langoy'">
               <unit name=”firstName” startPos=”0” endPos=”20”/>
               <unit name=”lastName” startPos=”21” endPos=”30”/>
               <unit name=”fullName” startPos=”0” endPos=”30”/>
               <unit name=”age” startPos=”31” endPos=”33”/>
        <field>
 
        <field name=”subField” matchOn="1-4='Bard',11-16='Langoy'">
               <unit name=”sub1” startPos=”0” endPos=”20”/>
               <unit name=”sub2” startPos=”21” endPos=”30”/>
        <field>
    </fields>
 
    <sequences>
        …
    </sequences>
</fl:reader>

 

 

Regards,

Bård

 

Från: Tom Fennelly [mailto:[hidden email]]
Skickat: den 22 december 2009 10:33
Till: [hidden email]
Kopia: [hidden email]
Ämne: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

 

Yeah... that makes sense to me Bard.  In fact, I seem to remember someone looking for something similar with CSV i.e. wanting the CSVReader to support a record stream that contained multiple record/transaction types.

Lets move this conversation to the dev list if that's OK... please reply there.

What do people think of the following.... I usually like to start with the confg aspects i.e. how would I like to use this, and from what I hear from you guys, sound like we need the reader to support config of multiple fieldsets, as well definition of some form of matching rules e.g.

<fl:reader>
    <fieldsets>
        <fieldset fields="firstName[20]?trim,lastName[20]?trim,gender[6]?trim.upper_case,age[3]?trim,country[2]" matchOn="1-3='Tom',21-29='Fennelly'" />
        <fieldset fields="firstName[10]?trim,lastName[10]?trim,gender[6]?trim.upper_case"                        matchOn="1-4='Bard',11-16='Langoy'" />
    </fieldsets>
</fl:reader>
  

Would something like that work?

T.


Bård Langöy wrote:

Hi,
 
Yes, I think the best solution would be to extend the fixed length parser. Even though the EDIParser has a way of defining sequences it might not be sufficient for the fixed-length parser. First off the flat-file might need multiple values for matching  a line type... for example it would need the value at position 1-2 and also position 3-12 to decide the type of line/transaction that is being currently processed. Also, the sequence algorithm might be different from the EDIParser. When is it ok to invoke a new event in Smooks ? It might be the end of a transaction that consists of several lines in the input-file. The EDIParser on the opposite invokes a new event at first matching segment. 
 
I think these things should be considered before extending the EDIParser at least.
 
Regards,
Bård
 
-----Ursprungligt meddelande-----
Från: pembertona [[hidden email]] 
Skickat: den 21 december 2009 13:56
Till: [hidden email]
Ämne: Re: [milyn-user] SV: Smooks EDI fixed length question/feature request
 
 
Hey guys:
 
1) First, thanks for the quick replies.
 
2) to Tom's question... the data I'm dealing with is labeled "EDI", but uses
field length (with fixed and variable length segments) as a core part of the
syntax. To my understanding, EDI itself is not a specification, but a more
general classification of plain-text data transmission methods (which are
usually themselves proprietary specifications) - am I wrong here?
 
3) It is a nationally-recognized standard (in the US) for reporting
accident/injury information for Workers' Compensation purposes (see:
http://www.iaiabc.org/i4a/pages/index.cfm?pageid=3338) (unfortunately, you
have to be a 'member' to look at the EDI implementation
guide/specification).
 
4) I tried to attach the following to my original email before it was
approved, but don't think I made it:
 
 
"I've looked into the fixed-length cartridge on trunk, but it looks fairly
new and not as feature-rich as the EDI cartridge. So basically, I need the
EDI cartridge, with fixed-length processing at the field level."
 
It sounds like Bård hit the nail on the head - I'd need to extend the fixed
length cartridge (or EDI cartridge) to build out the functionality I need.
 
Thoughts?
-AP
 
  



--
Andy Pemberton
www.andypemberton.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Tom Fennelly
In reply to this post by pembertona
Hey Andy... see my last email on this thread... seems to me like
adaptation of the EDI Parser (and config) is the way forward for this.

T.


Andy Pemberton wrote:

> The implementation guide for the specification itself is licensed; so
> I've included a sample file.
>
> The file structure looks like:
>
> Header Record
> First Report of Injury
> First Report of Injury Companion Record
> First Report of Injury
> First Report of Injury Companion Record
> Trailer Record
>
> So it's 1 transmission, with 1 batch of records, 1 header, 4
> transactions, and 1 trailer.
>
> -Andy
>
> On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hm…
>
>      
>
>     I would really like to see the specification for this. Just to
>     better grasp how the sequence flow is implemented. I will look
>     around if I can find an example file or something. Or could you
>     provide us with this Andy ? If the specs were licensed in some way
>     maybe just an example-file will do for now..
>
>      
>
>     Regards,
>
>     Bård
>
>
> --
> Andy Pemberton
> www.andypemberton.com <http://www.andypemberton.com>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

pembertona
Thanks, Tom.

That was actually my initial gut feeling, as it seems the EDI parser has most of what I need; it only lacks the fixed length field feature, really.

I've actually got a configuration going that (so far) will build out the structure properly down to the field level.

I'll take a look at extending the EDI cartridge this week, starting (as you suggested) with the configuration - I'll email back to this list for your thoughts.

Thanks again,
-Andy


On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]> wrote:
Hey Andy... see my last email on this thread... seems to me like adaptation of the EDI Parser (and config) is the way forward for this.

T.


Andy Pemberton wrote:
The implementation guide for the specification itself is licensed; so I've included a sample file.

The file structure looks like:

Header Record
First Report of Injury
First Report of Injury Companion Record
First Report of Injury
First Report of Injury Companion Record
Trailer Record

So it's 1 transmission, with 1 batch of records, 1 header, 4 transactions, and 1 trailer.

-Andy

On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email] <mailto:[hidden email]>> wrote:

   Hm…

   
   I would really like to see the specification for this. Just to
   better grasp how the sequence flow is implemented. I will look
   around if I can find an example file or something. Or could you
   provide us with this Andy ? If the specs were licensed in some way
   maybe just an example-file will do for now..

   
   Regards,

   Bård


--
Andy Pemberton
www.andypemberton.com <http://www.andypemberton.com>

------------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email
 

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email





--
Andy Pemberton
www.andypemberton.com
Reply | Threaded
Open this post in threaded view
|

Re: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Tom Fennelly
Hi Andy.

Right, starting with the config is good.  You'll need to create a new
config version.

Regards,

T.


Andy Pemberton wrote:

> Thanks, Tom.
>
> That was actually my initial gut feeling, as it seems the EDI parser
> has most of what I need; it only lacks the fixed length field feature,
> really.
>
> I've actually got a configuration going that (so far) will build out
> the structure properly down to the field level.
>
> I'll take a look at extending the EDI cartridge this week, starting
> (as you suggested) with the configuration - I'll email back to this
> list for your thoughts.
>
> Thanks again,
> -Andy
>
>
> On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hey Andy... see my last email on this thread... seems to me like
>     adaptation of the EDI Parser (and config) is the way forward for this.
>
>     T.
>
>
>     Andy Pemberton wrote:
>
>         The implementation guide for the specification itself is
>         licensed; so I've included a sample file.
>
>         The file structure looks like:
>
>         Header Record
>         First Report of Injury
>         First Report of Injury Companion Record
>         First Report of Injury
>         First Report of Injury Companion Record
>         Trailer Record
>
>         So it's 1 transmission, with 1 batch of records, 1 header, 4
>         transactions, and 1 trailer.
>
>         -Andy
>
>         On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>> wrote:
>
>            Hm…
>
>            
>            I would really like to see the specification for this. Just to
>            better grasp how the sequence flow is implemented. I will look
>            around if I can find an example file or something. Or could you
>            provide us with this Andy ? If the specs were licensed in
>         some way
>            maybe just an example-file will do for now..
>
>            
>            Regards,
>
>            Bård
>
>
>         --
>         Andy Pemberton
>         www.andypemberton.com <http://www.andypemberton.com>
>         <http://www.andypemberton.com>
>
>         ------------------------------------------------------------------------
>
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
>
>            http://xircles.codehaus.org/manage_email
>          
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>
>
>
> --
> Andy Pemberton
> www.andypemberton.com <http://www.andypemberton.com>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Bård Langöy
Hi,

Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?

regards,
Bård
________________________________________
Från: Tom Fennelly [[hidden email]]
Skickat: den 26 december 2009 08:44
Till: [hidden email]
Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request

Hi Andy.

Right, starting with the config is good.  You'll need to create a new
config version.

Regards,

T.


Andy Pemberton wrote:

> Thanks, Tom.
>
> That was actually my initial gut feeling, as it seems the EDI parser
> has most of what I need; it only lacks the fixed length field feature,
> really.
>
> I've actually got a configuration going that (so far) will build out
> the structure properly down to the field level.
>
> I'll take a look at extending the EDI cartridge this week, starting
> (as you suggested) with the configuration - I'll email back to this
> list for your thoughts.
>
> Thanks again,
> -Andy
>
>
> On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Hey Andy... see my last email on this thread... seems to me like
>     adaptation of the EDI Parser (and config) is the way forward for this.
>
>     T.
>
>
>     Andy Pemberton wrote:
>
>         The implementation guide for the specification itself is
>         licensed; so I've included a sample file.
>
>         The file structure looks like:
>
>         Header Record
>         First Report of Injury
>         First Report of Injury Companion Record
>         First Report of Injury
>         First Report of Injury Companion Record
>         Trailer Record
>
>         So it's 1 transmission, with 1 batch of records, 1 header, 4
>         transactions, and 1 trailer.
>
>         -Andy
>
>         On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
>         <mailto:[hidden email]> <mailto:[hidden email]
>         <mailto:[hidden email]>>> wrote:
>
>            Hm…
>
>
>            I would really like to see the specification for this. Just to
>            better grasp how the sequence flow is implemented. I will look
>            around if I can find an example file or something. Or could you
>            provide us with this Andy ? If the specs were licensed in
>         some way
>            maybe just an example-file will do for now..
>
>
>            Regards,
>
>            Bård
>
>
>         --
>         Andy Pemberton
>         www.andypemberton.com <http://www.andypemberton.com>
>         <http://www.andypemberton.com>
>
>         ------------------------------------------------------------------------
>
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
>
>            http://xircles.codehaus.org/manage_email
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>
>
>
> --
> Andy Pemberton
> www.andypemberton.com <http://www.andypemberton.com>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Tom Fennelly
Not sure Bard.... I thought there'd be one at each component level in
the model e.g....

    <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
    <medi:field xmltag="order-id"  matchOn="4-10"/>
    <medi:field xmltag="status-code" matchOn="11='A'"/>
    <medi:field xmltag="net-amount" matchOn="12-22"/>
    <medi:field xmltag="total-amount" matchOn="23-33"/>
    <medi:field xmltag="tax" matchOn="34-44"/>
    <medi:field xmltag="date" matchOn="45-55"/>
    </medi:segment>

T.


Bård Langöy wrote:

> Hi,
>
> Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?
>
> regards,
> Bård
> ________________________________________
> Från: Tom Fennelly [[hidden email]]
> Skickat: den 26 december 2009 08:44
> Till: [hidden email]
> Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request
>
> Hi Andy.
>
> Right, starting with the config is good.  You'll need to create a new
> config version.
>
> Regards,
>
> T.
>
>
> Andy Pemberton wrote:
>  
>> Thanks, Tom.
>>
>> That was actually my initial gut feeling, as it seems the EDI parser
>> has most of what I need; it only lacks the fixed length field feature,
>> really.
>>
>> I've actually got a configuration going that (so far) will build out
>> the structure properly down to the field level.
>>
>> I'll take a look at extending the EDI cartridge this week, starting
>> (as you suggested) with the configuration - I'll email back to this
>> list for your thoughts.
>>
>> Thanks again,
>> -Andy
>>
>>
>> On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Hey Andy... see my last email on this thread... seems to me like
>>     adaptation of the EDI Parser (and config) is the way forward for this.
>>
>>     T.
>>
>>
>>     Andy Pemberton wrote:
>>
>>         The implementation guide for the specification itself is
>>         licensed; so I've included a sample file.
>>
>>         The file structure looks like:
>>
>>         Header Record
>>         First Report of Injury
>>         First Report of Injury Companion Record
>>         First Report of Injury
>>         First Report of Injury Companion Record
>>         Trailer Record
>>
>>         So it's 1 transmission, with 1 batch of records, 1 header, 4
>>         transactions, and 1 trailer.
>>
>>         -Andy
>>
>>         On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
>>         <mailto:[hidden email]> <mailto:[hidden email]
>>         <mailto:[hidden email]>>> wrote:
>>
>>            Hm…
>>
>>
>>            I would really like to see the specification for this. Just to
>>            better grasp how the sequence flow is implemented. I will look
>>            around if I can find an example file or something. Or could you
>>            provide us with this Andy ? If the specs were licensed in
>>         some way
>>            maybe just an example-file will do for now..
>>
>>
>>            Regards,
>>
>>            Bård
>>
>>
>>         --
>>         Andy Pemberton
>>         www.andypemberton.com <http://www.andypemberton.com>
>>         <http://www.andypemberton.com>
>>
>>         ------------------------------------------------------------------------
>>
>>         ---------------------------------------------------------------------
>>         To unsubscribe from this list, please visit:
>>
>>            http://xircles.codehaus.org/manage_email
>>
>>
>>
>>     ---------------------------------------------------------------------
>>     To unsubscribe from this list, please visit:
>>
>>       http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>>
>> --
>> Andy Pemberton
>> www.andypemberton.com <http://www.andypemberton.com>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

SV: SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Bård Langöy
Hi,

But should we not separate the matchOn attribute from the actual value extraction ?

So, on segment level we have the matchOn that does the actual match. On each "leaf" component, which should be only fields in Andy's case, we should have something like a startPos and endPos or something like that.

Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [mailto:[hidden email]]
Skickat: den 28 december 2009 08:28
Till: [hidden email]
Ämne: Re: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Not sure Bard.... I thought there'd be one at each component level in
the model e.g....

    <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
    <medi:field xmltag="order-id"  matchOn="4-10"/>
    <medi:field xmltag="status-code" matchOn="11='A'"/>
    <medi:field xmltag="net-amount" matchOn="12-22"/>
    <medi:field xmltag="total-amount" matchOn="23-33"/>
    <medi:field xmltag="tax" matchOn="34-44"/>
    <medi:field xmltag="date" matchOn="45-55"/>
    </medi:segment>

T.


Bård Langöy wrote:

> Hi,
>
> Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?
>
> regards,
> Bård
> ________________________________________
> Från: Tom Fennelly [[hidden email]]
> Skickat: den 26 december 2009 08:44
> Till: [hidden email]
> Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request
>
> Hi Andy.
>
> Right, starting with the config is good.  You'll need to create a new
> config version.
>
> Regards,
>
> T.
>
>
> Andy Pemberton wrote:
>  
>> Thanks, Tom.
>>
>> That was actually my initial gut feeling, as it seems the EDI parser
>> has most of what I need; it only lacks the fixed length field feature,
>> really.
>>
>> I've actually got a configuration going that (so far) will build out
>> the structure properly down to the field level.
>>
>> I'll take a look at extending the EDI cartridge this week, starting
>> (as you suggested) with the configuration - I'll email back to this
>> list for your thoughts.
>>
>> Thanks again,
>> -Andy
>>
>>
>> On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     Hey Andy... see my last email on this thread... seems to me like
>>     adaptation of the EDI Parser (and config) is the way forward for this.
>>
>>     T.
>>
>>
>>     Andy Pemberton wrote:
>>
>>         The implementation guide for the specification itself is
>>         licensed; so I've included a sample file.
>>
>>         The file structure looks like:
>>
>>         Header Record
>>         First Report of Injury
>>         First Report of Injury Companion Record
>>         First Report of Injury
>>         First Report of Injury Companion Record
>>         Trailer Record
>>
>>         So it's 1 transmission, with 1 batch of records, 1 header, 4
>>         transactions, and 1 trailer.
>>
>>         -Andy
>>
>>         On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
>>         <mailto:[hidden email]> <mailto:[hidden email]
>>         <mailto:[hidden email]>>> wrote:
>>
>>            Hm.
>>
>>
>>            I would really like to see the specification for this. Just to
>>            better grasp how the sequence flow is implemented. I will look
>>            around if I can find an example file or something. Or could you
>>            provide us with this Andy ? If the specs were licensed in
>>         some way
>>            maybe just an example-file will do for now..
>>
>>
>>            Regards,
>>
>>            Bård
>>
>>
>>         --
>>         Andy Pemberton
>>         www.andypemberton.com <http://www.andypemberton.com>
>>         <http://www.andypemberton.com>
>>
>>         ------------------------------------------------------------------------
>>
>>         ---------------------------------------------------------------------
>>         To unsubscribe from this list, please visit:
>>
>>            http://xircles.codehaus.org/manage_email
>>
>>
>>
>>     ---------------------------------------------------------------------
>>     To unsubscribe from this list, please visit:
>>
>>       http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>>
>> --
>> Andy Pemberton
>> www.andypemberton.com <http://www.andypemberton.com>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: SV: SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Tom Fennelly
Can you show an example Bard?

So in what I was suggesting there, the segment would be matched based on
an effective accumulation of the matchOn configs for the components of
the segment i.e. code that reads something like "if  chars 0-3 = 'HDR'
and  char 11 = 'A'".

I thought that read OK in the config (easy for the user to see how
individual fields etc are being matched + no duplication between the
matchOn on the segment and the start/end attribute vals), but I
obviously need to see what you have in mind Bard.

T.

Bård Langöy wrote:

> Hi,
>
> But should we not separate the matchOn attribute from the actual value extraction ?
>
> So, on segment level we have the matchOn that does the actual match. On each "leaf" component, which should be only fields in Andy's case, we should have something like a startPos and endPos or something like that.
>
> Regards,
> Bård
>
> -----Ursprungligt meddelande-----
> Från: Tom Fennelly [mailto:[hidden email]]
> Skickat: den 28 december 2009 08:28
> Till: [hidden email]
> Ämne: Re: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>
> Not sure Bard.... I thought there'd be one at each component level in
> the model e.g....
>
>     <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>     <medi:field xmltag="order-id"  matchOn="4-10"/>
>     <medi:field xmltag="status-code" matchOn="11='A'"/>
>     <medi:field xmltag="net-amount" matchOn="12-22"/>
>     <medi:field xmltag="total-amount" matchOn="23-33"/>
>     <medi:field xmltag="tax" matchOn="34-44"/>
>     <medi:field xmltag="date" matchOn="45-55"/>
>     </medi:segment>
>
> T.
>
>
> Bård Langöy wrote:
>  
>> Hi,
>>
>> Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?
>>
>> regards,
>> Bård
>> ________________________________________
>> Från: Tom Fennelly [[hidden email]]
>> Skickat: den 26 december 2009 08:44
>> Till: [hidden email]
>> Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request
>>
>> Hi Andy.
>>
>> Right, starting with the config is good.  You'll need to create a new
>> config version.
>>
>> Regards,
>>
>> T.
>>
>>
>> Andy Pemberton wrote:
>>  
>>    
>>> Thanks, Tom.
>>>
>>> That was actually my initial gut feeling, as it seems the EDI parser
>>> has most of what I need; it only lacks the fixed length field feature,
>>> really.
>>>
>>> I've actually got a configuration going that (so far) will build out
>>> the structure properly down to the field level.
>>>
>>> I'll take a look at extending the EDI cartridge this week, starting
>>> (as you suggested) with the configuration - I'll email back to this
>>> list for your thoughts.
>>>
>>> Thanks again,
>>> -Andy
>>>
>>>
>>> On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>     Hey Andy... see my last email on this thread... seems to me like
>>>     adaptation of the EDI Parser (and config) is the way forward for this.
>>>
>>>     T.
>>>
>>>
>>>     Andy Pemberton wrote:
>>>
>>>         The implementation guide for the specification itself is
>>>         licensed; so I've included a sample file.
>>>
>>>         The file structure looks like:
>>>
>>>         Header Record
>>>         First Report of Injury
>>>         First Report of Injury Companion Record
>>>         First Report of Injury
>>>         First Report of Injury Companion Record
>>>         Trailer Record
>>>
>>>         So it's 1 transmission, with 1 batch of records, 1 header, 4
>>>         transactions, and 1 trailer.
>>>
>>>         -Andy
>>>
>>>         On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
>>>         <mailto:[hidden email]> <mailto:[hidden email]
>>>         <mailto:[hidden email]>>> wrote:
>>>
>>>            Hm.
>>>
>>>
>>>            I would really like to see the specification for this. Just to
>>>            better grasp how the sequence flow is implemented. I will look
>>>            around if I can find an example file or something. Or could you
>>>            provide us with this Andy ? If the specs were licensed in
>>>         some way
>>>            maybe just an example-file will do for now..
>>>
>>>
>>>            Regards,
>>>
>>>            Bård
>>>
>>>
>>>         --
>>>         Andy Pemberton
>>>         www.andypemberton.com <http://www.andypemberton.com>
>>>         <http://www.andypemberton.com>
>>>
>>>         ------------------------------------------------------------------------
>>>
>>>         ---------------------------------------------------------------------
>>>         To unsubscribe from this list, please visit:
>>>
>>>            http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>     ---------------------------------------------------------------------
>>>     To unsubscribe from this list, please visit:
>>>
>>>       http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Andy Pemberton
>>> www.andypemberton.com <http://www.andypemberton.com>
>>>    
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>  
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

SV: SV: SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Bård Langöy
Hi Tom,

Yes, what I had in mind is that it is only the segment element that needs the matchOn attribute. If the line matches then it is time to extract the values specified in the field-components. And for extracting those values you need to know the location/position of the values since there are no delimiters. And it is not possible to do a matchOn since the value can vary. So I think that we think alike but the matchOn could be a bit confusing since we are not doing a match in this case but actually a value-extraction at the given position.

So an example of this config would be something like:

<medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>     <medi:field xmltag="order-id"  position="4-10"/>
>     <medi:field xmltag="status-code" position ="11='A'"/>
>     <medi:field xmltag="net-amount" position ="12-22"/>
>     <medi:field xmltag="total-amount" position ="23-33"/>
>     <medi:field xmltag="tax" position="34-44"/>
>     <medi:field xmltag="date" position ="45-55"/>
>     </medi:segment>


What do you think ?

Regards,
Bård


-----Ursprungligt meddelande-----
Från: Tom Fennelly [mailto:[hidden email]]
Skickat: den 28 december 2009 09:42
Till: [hidden email]
Ämne: Re: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Can you show an example Bard?

So in what I was suggesting there, the segment would be matched based on
an effective accumulation of the matchOn configs for the components of
the segment i.e. code that reads something like "if  chars 0-3 = 'HDR'
and  char 11 = 'A'".

I thought that read OK in the config (easy for the user to see how
individual fields etc are being matched + no duplication between the
matchOn on the segment and the start/end attribute vals), but I
obviously need to see what you have in mind Bard.

T.

Bård Langöy wrote:

> Hi,
>
> But should we not separate the matchOn attribute from the actual value extraction ?
>
> So, on segment level we have the matchOn that does the actual match. On each "leaf" component, which should be only fields in Andy's case, we should have something like a startPos and endPos or something like that.
>
> Regards,
> Bård
>
> -----Ursprungligt meddelande-----
> Från: Tom Fennelly [mailto:[hidden email]]
> Skickat: den 28 december 2009 08:28
> Till: [hidden email]
> Ämne: Re: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>
> Not sure Bard.... I thought there'd be one at each component level in
> the model e.g....
>
>     <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>     <medi:field xmltag="order-id"  matchOn="4-10"/>
>     <medi:field xmltag="status-code" matchOn="11='A'"/>
>     <medi:field xmltag="net-amount" matchOn="12-22"/>
>     <medi:field xmltag="total-amount" matchOn="23-33"/>
>     <medi:field xmltag="tax" matchOn="34-44"/>
>     <medi:field xmltag="date" matchOn="45-55"/>
>     </medi:segment>
>
> T.
>
>
> Bård Langöy wrote:
>  
>> Hi,
>>
>> Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?
>>
>> regards,
>> Bård
>> ________________________________________
>> Från: Tom Fennelly [[hidden email]]
>> Skickat: den 26 december 2009 08:44
>> Till: [hidden email]
>> Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request
>>
>> Hi Andy.
>>
>> Right, starting with the config is good.  You'll need to create a new
>> config version.
>>
>> Regards,
>>
>> T.
>>
>>
>> Andy Pemberton wrote:
>>  
>>    
>>> Thanks, Tom.
>>>
>>> That was actually my initial gut feeling, as it seems the EDI parser
>>> has most of what I need; it only lacks the fixed length field feature,
>>> really.
>>>
>>> I've actually got a configuration going that (so far) will build out
>>> the structure properly down to the field level.
>>>
>>> I'll take a look at extending the EDI cartridge this week, starting
>>> (as you suggested) with the configuration - I'll email back to this
>>> list for your thoughts.
>>>
>>> Thanks again,
>>> -Andy
>>>
>>>
>>> On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>     Hey Andy... see my last email on this thread... seems to me like
>>>     adaptation of the EDI Parser (and config) is the way forward for this.
>>>
>>>     T.
>>>
>>>
>>>     Andy Pemberton wrote:
>>>
>>>         The implementation guide for the specification itself is
>>>         licensed; so I've included a sample file.
>>>
>>>         The file structure looks like:
>>>
>>>         Header Record
>>>         First Report of Injury
>>>         First Report of Injury Companion Record
>>>         First Report of Injury
>>>         First Report of Injury Companion Record
>>>         Trailer Record
>>>
>>>         So it's 1 transmission, with 1 batch of records, 1 header, 4
>>>         transactions, and 1 trailer.
>>>
>>>         -Andy
>>>
>>>         On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
>>>         <mailto:[hidden email]> <mailto:[hidden email]
>>>         <mailto:[hidden email]>>> wrote:
>>>
>>>            Hm.
>>>
>>>
>>>            I would really like to see the specification for this. Just to
>>>            better grasp how the sequence flow is implemented. I will look
>>>            around if I can find an example file or something. Or could you
>>>            provide us with this Andy ? If the specs were licensed in
>>>         some way
>>>            maybe just an example-file will do for now..
>>>
>>>
>>>            Regards,
>>>
>>>            Bård
>>>
>>>
>>>         --
>>>         Andy Pemberton
>>>         www.andypemberton.com <http://www.andypemberton.com>
>>>         <http://www.andypemberton.com>
>>>
>>>         ------------------------------------------------------------------------
>>>
>>>         ---------------------------------------------------------------------
>>>         To unsubscribe from this list, please visit:
>>>
>>>            http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>     ---------------------------------------------------------------------
>>>     To unsubscribe from this list, please visit:
>>>
>>>       http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Andy Pemberton
>>> www.andypemberton.com <http://www.andypemberton.com>
>>>    
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>  
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: SV: SV: SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Tom Fennelly
:)  are they they same, except the attribute on the field element is
named "position" Vs "matchOn"?  I'm OK with naming them "position", but
I would also rename the matchOn attribute on the segment to "position"
too... I think having them different would be quite confusing (at least
to me, they are logically the same thing).

T.

Bård Langöy wrote:

> Hi Tom,
>
> Yes, what I had in mind is that it is only the segment element that needs the matchOn attribute. If the line matches then it is time to extract the values specified in the field-components. And for extracting those values you need to know the location/position of the values since there are no delimiters. And it is not possible to do a matchOn since the value can vary. So I think that we think alike but the matchOn could be a bit confusing since we are not doing a match in this case but actually a value-extraction at the given position.
>
> So an example of this config would be something like:
>
> <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>  
>>     <medi:field xmltag="order-id"  position="4-10"/>
>>     <medi:field xmltag="status-code" position ="11='A'"/>
>>     <medi:field xmltag="net-amount" position ="12-22"/>
>>     <medi:field xmltag="total-amount" position ="23-33"/>
>>     <medi:field xmltag="tax" position="34-44"/>
>>     <medi:field xmltag="date" position ="45-55"/>
>>     </medi:segment>
>>    
>
>
> What do you think ?
>
> Regards,
> Bård
>
>
> -----Ursprungligt meddelande-----
> Från: Tom Fennelly [mailto:[hidden email]]
> Skickat: den 28 december 2009 09:42
> Till: [hidden email]
> Ämne: Re: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>
> Can you show an example Bard?
>
> So in what I was suggesting there, the segment would be matched based on
> an effective accumulation of the matchOn configs for the components of
> the segment i.e. code that reads something like "if  chars 0-3 = 'HDR'
> and  char 11 = 'A'".
>
> I thought that read OK in the config (easy for the user to see how
> individual fields etc are being matched + no duplication between the
> matchOn on the segment and the start/end attribute vals), but I
> obviously need to see what you have in mind Bard.
>
> T.
>
> Bård Langöy wrote:
>  
>> Hi,
>>
>> But should we not separate the matchOn attribute from the actual value extraction ?
>>
>> So, on segment level we have the matchOn that does the actual match. On each "leaf" component, which should be only fields in Andy's case, we should have something like a startPos and endPos or something like that.
>>
>> Regards,
>> Bård
>>
>> -----Ursprungligt meddelande-----
>> Från: Tom Fennelly [mailto:[hidden email]]
>> Skickat: den 28 december 2009 08:28
>> Till: [hidden email]
>> Ämne: Re: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>>
>> Not sure Bard.... I thought there'd be one at each component level in
>> the model e.g....
>>
>>     <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>>     <medi:field xmltag="order-id"  matchOn="4-10"/>
>>     <medi:field xmltag="status-code" matchOn="11='A'"/>
>>     <medi:field xmltag="net-amount" matchOn="12-22"/>
>>     <medi:field xmltag="total-amount" matchOn="23-33"/>
>>     <medi:field xmltag="tax" matchOn="34-44"/>
>>     <medi:field xmltag="date" matchOn="45-55"/>
>>     </medi:segment>
>>
>> T.
>>
>>
>> Bård Langöy wrote:
>>  
>>    
>>> Hi,
>>>
>>> Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?
>>>
>>> regards,
>>> Bård
>>> ________________________________________
>>> Från: Tom Fennelly [[hidden email]]
>>> Skickat: den 26 december 2009 08:44
>>> Till: [hidden email]
>>> Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request
>>>
>>> Hi Andy.
>>>
>>> Right, starting with the config is good.  You'll need to create a new
>>> config version.
>>>
>>> Regards,
>>>
>>> T.
>>>
>>>
>>> Andy Pemberton wrote:
>>>  
>>>    
>>>      
>>>> Thanks, Tom.
>>>>
>>>> That was actually my initial gut feeling, as it seems the EDI parser
>>>> has most of what I need; it only lacks the fixed length field feature,
>>>> really.
>>>>
>>>> I've actually got a configuration going that (so far) will build out
>>>> the structure properly down to the field level.
>>>>
>>>> I'll take a look at extending the EDI cartridge this week, starting
>>>> (as you suggested) with the configuration - I'll email back to this
>>>> list for your thoughts.
>>>>
>>>> Thanks again,
>>>> -Andy
>>>>
>>>>
>>>> On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>>     Hey Andy... see my last email on this thread... seems to me like
>>>>     adaptation of the EDI Parser (and config) is the way forward for this.
>>>>
>>>>     T.
>>>>
>>>>
>>>>     Andy Pemberton wrote:
>>>>
>>>>         The implementation guide for the specification itself is
>>>>         licensed; so I've included a sample file.
>>>>
>>>>         The file structure looks like:
>>>>
>>>>         Header Record
>>>>         First Report of Injury
>>>>         First Report of Injury Companion Record
>>>>         First Report of Injury
>>>>         First Report of Injury Companion Record
>>>>         Trailer Record
>>>>
>>>>         So it's 1 transmission, with 1 batch of records, 1 header, 4
>>>>         transactions, and 1 trailer.
>>>>
>>>>         -Andy
>>>>
>>>>         On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
>>>>         <mailto:[hidden email]> <mailto:[hidden email]
>>>>         <mailto:[hidden email]>>> wrote:
>>>>
>>>>            Hm.
>>>>
>>>>
>>>>            I would really like to see the specification for this. Just to
>>>>            better grasp how the sequence flow is implemented. I will look
>>>>            around if I can find an example file or something. Or could you
>>>>            provide us with this Andy ? If the specs were licensed in
>>>>         some way
>>>>            maybe just an example-file will do for now..
>>>>
>>>>
>>>>            Regards,
>>>>
>>>>            Bård
>>>>
>>>>
>>>>         --
>>>>         Andy Pemberton
>>>>         www.andypemberton.com <http://www.andypemberton.com>
>>>>         <http://www.andypemberton.com>
>>>>
>>>>         ------------------------------------------------------------------------
>>>>
>>>>         ---------------------------------------------------------------------
>>>>         To unsubscribe from this list, please visit:
>>>>
>>>>            http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>     ---------------------------------------------------------------------
>>>>     To unsubscribe from this list, please visit:
>>>>
>>>>       http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Andy Pemberton
>>>> www.andypemberton.com <http://www.andypemberton.com>
>>>>    
>>>>      
>>>>        
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>  
>>>    
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>  
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

SV: SV: SV: SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Bård Langöy
Hi Tom,

Ah ok... because to me they are logically different :) I think I am just bad at explaining myself here.

So, what I mean is that at Segment level the matchOn attribute is used to tell the EDIParser at what position the segcode is located. I.e. there are no value extraction at this point... but at the components level the position attribute is used to actually used to extract the value at the given position, so there will be no matching at that point.

But I have no strong opinions about this... I just think that the operations at segment level and component level are different. But if you think it will be easier for users to have the same attribute I say we go for that !


Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [mailto:[hidden email]]
Skickat: den 28 december 2009 15:03
Till: [hidden email]
Ämne: Re: SV: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

:)  are they they same, except the attribute on the field element is
named "position" Vs "matchOn"?  I'm OK with naming them "position", but
I would also rename the matchOn attribute on the segment to "position"
too... I think having them different would be quite confusing (at least
to me, they are logically the same thing).

T.

Bård Langöy wrote:

> Hi Tom,
>
> Yes, what I had in mind is that it is only the segment element that needs the matchOn attribute. If the line matches then it is time to extract the values specified in the field-components. And for extracting those values you need to know the location/position of the values since there are no delimiters. And it is not possible to do a matchOn since the value can vary. So I think that we think alike but the matchOn could be a bit confusing since we are not doing a match in this case but actually a value-extraction at the given position.
>
> So an example of this config would be something like:
>
> <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>  
>>     <medi:field xmltag="order-id"  position="4-10"/>
>>     <medi:field xmltag="status-code" position ="11='A'"/>
>>     <medi:field xmltag="net-amount" position ="12-22"/>
>>     <medi:field xmltag="total-amount" position ="23-33"/>
>>     <medi:field xmltag="tax" position="34-44"/>
>>     <medi:field xmltag="date" position ="45-55"/>
>>     </medi:segment>
>>    
>
>
> What do you think ?
>
> Regards,
> Bård
>
>
> -----Ursprungligt meddelande-----
> Från: Tom Fennelly [mailto:[hidden email]]
> Skickat: den 28 december 2009 09:42
> Till: [hidden email]
> Ämne: Re: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>
> Can you show an example Bard?
>
> So in what I was suggesting there, the segment would be matched based on
> an effective accumulation of the matchOn configs for the components of
> the segment i.e. code that reads something like "if  chars 0-3 = 'HDR'
> and  char 11 = 'A'".
>
> I thought that read OK in the config (easy for the user to see how
> individual fields etc are being matched + no duplication between the
> matchOn on the segment and the start/end attribute vals), but I
> obviously need to see what you have in mind Bard.
>
> T.
>
> Bård Langöy wrote:
>  
>> Hi,
>>
>> But should we not separate the matchOn attribute from the actual value extraction ?
>>
>> So, on segment level we have the matchOn that does the actual match. On each "leaf" component, which should be only fields in Andy's case, we should have something like a startPos and endPos or something like that.
>>
>> Regards,
>> Bård
>>
>> -----Ursprungligt meddelande-----
>> Från: Tom Fennelly [mailto:[hidden email]]
>> Skickat: den 28 december 2009 08:28
>> Till: [hidden email]
>> Ämne: Re: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>>
>> Not sure Bard.... I thought there'd be one at each component level in
>> the model e.g....
>>
>>     <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>>     <medi:field xmltag="order-id"  matchOn="4-10"/>
>>     <medi:field xmltag="status-code" matchOn="11='A'"/>
>>     <medi:field xmltag="net-amount" matchOn="12-22"/>
>>     <medi:field xmltag="total-amount" matchOn="23-33"/>
>>     <medi:field xmltag="tax" matchOn="34-44"/>
>>     <medi:field xmltag="date" matchOn="45-55"/>
>>     </medi:segment>
>>
>> T.
>>
>>
>> Bård Langöy wrote:
>>  
>>    
>>> Hi,
>>>
>>> Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?
>>>
>>> regards,
>>> Bård
>>> ________________________________________
>>> Från: Tom Fennelly [[hidden email]]
>>> Skickat: den 26 december 2009 08:44
>>> Till: [hidden email]
>>> Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request
>>>
>>> Hi Andy.
>>>
>>> Right, starting with the config is good.  You'll need to create a new
>>> config version.
>>>
>>> Regards,
>>>
>>> T.
>>>
>>>
>>> Andy Pemberton wrote:
>>>  
>>>    
>>>      
>>>> Thanks, Tom.
>>>>
>>>> That was actually my initial gut feeling, as it seems the EDI parser
>>>> has most of what I need; it only lacks the fixed length field feature,
>>>> really.
>>>>
>>>> I've actually got a configuration going that (so far) will build out
>>>> the structure properly down to the field level.
>>>>
>>>> I'll take a look at extending the EDI cartridge this week, starting
>>>> (as you suggested) with the configuration - I'll email back to this
>>>> list for your thoughts.
>>>>
>>>> Thanks again,
>>>> -Andy
>>>>
>>>>
>>>> On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
>>>> <mailto:[hidden email]>> wrote:
>>>>
>>>>     Hey Andy... see my last email on this thread... seems to me like
>>>>     adaptation of the EDI Parser (and config) is the way forward for this.
>>>>
>>>>     T.
>>>>
>>>>
>>>>     Andy Pemberton wrote:
>>>>
>>>>         The implementation guide for the specification itself is
>>>>         licensed; so I've included a sample file.
>>>>
>>>>         The file structure looks like:
>>>>
>>>>         Header Record
>>>>         First Report of Injury
>>>>         First Report of Injury Companion Record
>>>>         First Report of Injury
>>>>         First Report of Injury Companion Record
>>>>         Trailer Record
>>>>
>>>>         So it's 1 transmission, with 1 batch of records, 1 header, 4
>>>>         transactions, and 1 trailer.
>>>>
>>>>         -Andy
>>>>
>>>>         On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
>>>>         <mailto:[hidden email]> <mailto:[hidden email]
>>>>         <mailto:[hidden email]>>> wrote:
>>>>
>>>>            Hm.
>>>>
>>>>
>>>>            I would really like to see the specification for this. Just to
>>>>            better grasp how the sequence flow is implemented. I will look
>>>>            around if I can find an example file or something. Or could you
>>>>            provide us with this Andy ? If the specs were licensed in
>>>>         some way
>>>>            maybe just an example-file will do for now..
>>>>
>>>>
>>>>            Regards,
>>>>
>>>>            Bård
>>>>
>>>>
>>>>         --
>>>>         Andy Pemberton
>>>>         www.andypemberton.com <http://www.andypemberton.com>
>>>>         <http://www.andypemberton.com>
>>>>
>>>>         ------------------------------------------------------------------------
>>>>
>>>>         ---------------------------------------------------------------------
>>>>         To unsubscribe from this list, please visit:
>>>>
>>>>            http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>     ---------------------------------------------------------------------
>>>>     To unsubscribe from this list, please visit:
>>>>
>>>>       http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Andy Pemberton
>>>> www.andypemberton.com <http://www.andypemberton.com>
>>>>    
>>>>      
>>>>        
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>  
>>>    
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>  
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: SV: SV: SV: SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Tom Fennelly
Ah ok Bard... so in my mind the matchOn/position would be used for  both
matching and extraction.

The parser could:

   1. Look at all of it's components, looking for position/matchOn
      attributes that contain explicit values (i.e. position="11='A'" Vs
      just position="11").
   2. Build an segment evaluate expression from all of these so as to
      perform a match for the segment
   3. Execute the expression on the segment text blob.  If the segment
      is a match, then it
          * uses the same matchOn/position range values to extract the
            values for the fields, components etc.

I think if you have the matchOn at the segment level only, then you
probably end up with duplication by specifying the same ranges in both
the matchOn on the segment, as well as some of the field/component elements.

Does that add up do you think?

T.

Bård Langöy wrote:

> Hi Tom,
>
> Ah ok... because to me they are logically different :) I think I am just bad at explaining myself here.
>
> So, what I mean is that at Segment level the matchOn attribute is used to tell the EDIParser at what position the segcode is located. I.e. there are no value extraction at this point... but at the components level the position attribute is used to actually used to extract the value at the given position, so there will be no matching at that point.
>
> But I have no strong opinions about this... I just think that the operations at segment level and component level are different. But if you think it will be easier for users to have the same attribute I say we go for that !
>
>
> Regards,
> Bård
>
> -----Ursprungligt meddelande-----
> Från: Tom Fennelly [mailto:[hidden email]]
> Skickat: den 28 december 2009 15:03
> Till: [hidden email]
> Ämne: Re: SV: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>
> :)  are they they same, except the attribute on the field element is
> named "position" Vs "matchOn"?  I'm OK with naming them "position", but
> I would also rename the matchOn attribute on the segment to "position"
> too... I think having them different would be quite confusing (at least
> to me, they are logically the same thing).
>
> T.
>
> Bård Langöy wrote:
>  
>> Hi Tom,
>>
>> Yes, what I had in mind is that it is only the segment element that needs the matchOn attribute. If the line matches then it is time to extract the values specified in the field-components. And for extracting those values you need to know the location/position of the values since there are no delimiters. And it is not possible to do a matchOn since the value can vary. So I think that we think alike but the matchOn could be a bit confusing since we are not doing a match in this case but actually a value-extraction at the given position.
>>
>> So an example of this config would be something like:
>>
>> <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>>  
>>    
>>>     <medi:field xmltag="order-id"  position="4-10"/>
>>>     <medi:field xmltag="status-code" position ="11='A'"/>
>>>     <medi:field xmltag="net-amount" position ="12-22"/>
>>>     <medi:field xmltag="total-amount" position ="23-33"/>
>>>     <medi:field xmltag="tax" position="34-44"/>
>>>     <medi:field xmltag="date" position ="45-55"/>
>>>     </medi:segment>
>>>    
>>>      
>> What do you think ?
>>
>> Regards,
>> Bård
>>
>>
>> -----Ursprungligt meddelande-----
>> Från: Tom Fennelly [mailto:[hidden email]]
>> Skickat: den 28 december 2009 09:42
>> Till: [hidden email]
>> Ämne: Re: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>>
>> Can you show an example Bard?
>>
>> So in what I was suggesting there, the segment would be matched based on
>> an effective accumulation of the matchOn configs for the components of
>> the segment i.e. code that reads something like "if  chars 0-3 = 'HDR'
>> and  char 11 = 'A'".
>>
>> I thought that read OK in the config (easy for the user to see how
>> individual fields etc are being matched + no duplication between the
>> matchOn on the segment and the start/end attribute vals), but I
>> obviously need to see what you have in mind Bard.
>>
>> T.
>>
>> Bård Langöy wrote:
>>  
>>    
>>> Hi,
>>>
>>> But should we not separate the matchOn attribute from the actual value extraction ?
>>>
>>> So, on segment level we have the matchOn that does the actual match. On each "leaf" component, which should be only fields in Andy's case, we should have something like a startPos and endPos or something like that.
>>>
>>> Regards,
>>> Bård
>>>
>>> -----Ursprungligt meddelande-----
>>> Från: Tom Fennelly [mailto:[hidden email]]
>>> Skickat: den 28 december 2009 08:28
>>> Till: [hidden email]
>>> Ämne: Re: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>>>
>>> Not sure Bard.... I thought there'd be one at each component level in
>>> the model e.g....
>>>
>>>     <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>>>     <medi:field xmltag="order-id"  matchOn="4-10"/>
>>>     <medi:field xmltag="status-code" matchOn="11='A'"/>
>>>     <medi:field xmltag="net-amount" matchOn="12-22"/>
>>>     <medi:field xmltag="total-amount" matchOn="23-33"/>
>>>     <medi:field xmltag="tax" matchOn="34-44"/>
>>>     <medi:field xmltag="date" matchOn="45-55"/>
>>>     </medi:segment>
>>>
>>> T.
>>>
>>>
>>> Bård Langöy wrote:
>>>  
>>>    
>>>      
>>>> Hi,
>>>>
>>>> Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?
>>>>
>>>> regards,
>>>> Bård
>>>> ________________________________________
>>>> Från: Tom Fennelly [[hidden email]]
>>>> Skickat: den 26 december 2009 08:44
>>>> Till: [hidden email]
>>>> Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request
>>>>
>>>> Hi Andy.
>>>>
>>>> Right, starting with the config is good.  You'll need to create a new
>>>> config version.
>>>>
>>>> Regards,
>>>>
>>>> T.
>>>>
>>>>
>>>> Andy Pemberton wrote:
>>>>  
>>>>    
>>>>      
>>>>        
>>>>> Thanks, Tom.
>>>>>
>>>>> That was actually my initial gut feeling, as it seems the EDI parser
>>>>> has most of what I need; it only lacks the fixed length field feature,
>>>>> really.
>>>>>
>>>>> I've actually got a configuration going that (so far) will build out
>>>>> the structure properly down to the field level.
>>>>>
>>>>> I'll take a look at extending the EDI cartridge this week, starting
>>>>> (as you suggested) with the configuration - I'll email back to this
>>>>> list for your thoughts.
>>>>>
>>>>> Thanks again,
>>>>> -Andy
>>>>>
>>>>>
>>>>> On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>>     Hey Andy... see my last email on this thread... seems to me like
>>>>>     adaptation of the EDI Parser (and config) is the way forward for this.
>>>>>
>>>>>     T.
>>>>>
>>>>>
>>>>>     Andy Pemberton wrote:
>>>>>
>>>>>         The implementation guide for the specification itself is
>>>>>         licensed; so I've included a sample file.
>>>>>
>>>>>         The file structure looks like:
>>>>>
>>>>>         Header Record
>>>>>         First Report of Injury
>>>>>         First Report of Injury Companion Record
>>>>>         First Report of Injury
>>>>>         First Report of Injury Companion Record
>>>>>         Trailer Record
>>>>>
>>>>>         So it's 1 transmission, with 1 batch of records, 1 header, 4
>>>>>         transactions, and 1 trailer.
>>>>>
>>>>>         -Andy
>>>>>
>>>>>         On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
>>>>>         <mailto:[hidden email]> <mailto:[hidden email]
>>>>>         <mailto:[hidden email]>>> wrote:
>>>>>
>>>>>            Hm.
>>>>>
>>>>>
>>>>>            I would really like to see the specification for this. Just to
>>>>>            better grasp how the sequence flow is implemented. I will look
>>>>>            around if I can find an example file or something. Or could you
>>>>>            provide us with this Andy ? If the specs were licensed in
>>>>>         some way
>>>>>            maybe just an example-file will do for now..
>>>>>
>>>>>
>>>>>            Regards,
>>>>>
>>>>>            Bård
>>>>>
>>>>>
>>>>>         --
>>>>>         Andy Pemberton
>>>>>         www.andypemberton.com <http://www.andypemberton.com>
>>>>>         <http://www.andypemberton.com>
>>>>>
>>>>>         ------------------------------------------------------------------------
>>>>>
>>>>>         ---------------------------------------------------------------------
>>>>>         To unsubscribe from this list, please visit:
>>>>>
>>>>>            http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>>     ---------------------------------------------------------------------
>>>>>     To unsubscribe from this list, please visit:
>>>>>
>>>>>       http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Andy Pemberton
>>>>> www.andypemberton.com <http://www.andypemberton.com>
>>>>>    
>>>>>      
>>>>>        
>>>>>          
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>     http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>     http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>  
>>>>    
>>>>      
>>>>        
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>  
>>>    
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>  
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

SV: SV: SV: SV: SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Bård Langöy
Hi Tom,

Ok I think I understand...

So then the matchOn value on component-level must always be the same as the value that you extract. You can in other words not check the value at position 11, and if that matches, extract the value from position 11-15.

Hmm... alright. I don't want to be difficult about this :). I still like the idea of splitting up the functionality but I can also see your point in that it might be easier for the user to configure. So if that is how we should do it then I like your attribute name (matchOn) best :).

Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [mailto:[hidden email]]
Skickat: den 28 december 2009 16:30
Till: [hidden email]
Ämne: Re: SV: SV: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Ah ok Bard... so in my mind the matchOn/position would be used for  both
matching and extraction.

The parser could:

   1. Look at all of it's components, looking for position/matchOn
      attributes that contain explicit values (i.e. position="11='A'" Vs
      just position="11").
   2. Build an segment evaluate expression from all of these so as to
      perform a match for the segment
   3. Execute the expression on the segment text blob.  If the segment
      is a match, then it
          * uses the same matchOn/position range values to extract the
            values for the fields, components etc.

I think if you have the matchOn at the segment level only, then you
probably end up with duplication by specifying the same ranges in both
the matchOn on the segment, as well as some of the field/component elements.

Does that add up do you think?

T.

Bård Langöy wrote:

> Hi Tom,
>
> Ah ok... because to me they are logically different :) I think I am just bad at explaining myself here.
>
> So, what I mean is that at Segment level the matchOn attribute is used to tell the EDIParser at what position the segcode is located. I.e. there are no value extraction at this point... but at the components level the position attribute is used to actually used to extract the value at the given position, so there will be no matching at that point.
>
> But I have no strong opinions about this... I just think that the operations at segment level and component level are different. But if you think it will be easier for users to have the same attribute I say we go for that !
>
>
> Regards,
> Bård
>
> -----Ursprungligt meddelande-----
> Från: Tom Fennelly [mailto:[hidden email]]
> Skickat: den 28 december 2009 15:03
> Till: [hidden email]
> Ämne: Re: SV: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>
> :)  are they they same, except the attribute on the field element is
> named "position" Vs "matchOn"?  I'm OK with naming them "position", but
> I would also rename the matchOn attribute on the segment to "position"
> too... I think having them different would be quite confusing (at least
> to me, they are logically the same thing).
>
> T.
>
> Bård Langöy wrote:
>  
>> Hi Tom,
>>
>> Yes, what I had in mind is that it is only the segment element that needs the matchOn attribute. If the line matches then it is time to extract the values specified in the field-components. And for extracting those values you need to know the location/position of the values since there are no delimiters. And it is not possible to do a matchOn since the value can vary. So I think that we think alike but the matchOn could be a bit confusing since we are not doing a match in this case but actually a value-extraction at the given position.
>>
>> So an example of this config would be something like:
>>
>> <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>>  
>>    
>>>     <medi:field xmltag="order-id"  position="4-10"/>
>>>     <medi:field xmltag="status-code" position ="11='A'"/>
>>>     <medi:field xmltag="net-amount" position ="12-22"/>
>>>     <medi:field xmltag="total-amount" position ="23-33"/>
>>>     <medi:field xmltag="tax" position="34-44"/>
>>>     <medi:field xmltag="date" position ="45-55"/>
>>>     </medi:segment>
>>>    
>>>      
>> What do you think ?
>>
>> Regards,
>> Bård
>>
>>
>> -----Ursprungligt meddelande-----
>> Från: Tom Fennelly [mailto:[hidden email]]
>> Skickat: den 28 december 2009 09:42
>> Till: [hidden email]
>> Ämne: Re: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>>
>> Can you show an example Bard?
>>
>> So in what I was suggesting there, the segment would be matched based on
>> an effective accumulation of the matchOn configs for the components of
>> the segment i.e. code that reads something like "if  chars 0-3 = 'HDR'
>> and  char 11 = 'A'".
>>
>> I thought that read OK in the config (easy for the user to see how
>> individual fields etc are being matched + no duplication between the
>> matchOn on the segment and the start/end attribute vals), but I
>> obviously need to see what you have in mind Bard.
>>
>> T.
>>
>> Bård Langöy wrote:
>>  
>>    
>>> Hi,
>>>
>>> But should we not separate the matchOn attribute from the actual value extraction ?
>>>
>>> So, on segment level we have the matchOn that does the actual match. On each "leaf" component, which should be only fields in Andy's case, we should have something like a startPos and endPos or something like that.
>>>
>>> Regards,
>>> Bård
>>>
>>> -----Ursprungligt meddelande-----
>>> Från: Tom Fennelly [mailto:[hidden email]]
>>> Skickat: den 28 december 2009 08:28
>>> Till: [hidden email]
>>> Ämne: Re: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request
>>>
>>> Not sure Bard.... I thought there'd be one at each component level in
>>> the model e.g....
>>>
>>>     <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
>>>     <medi:field xmltag="order-id"  matchOn="4-10"/>
>>>     <medi:field xmltag="status-code" matchOn="11='A'"/>
>>>     <medi:field xmltag="net-amount" matchOn="12-22"/>
>>>     <medi:field xmltag="total-amount" matchOn="23-33"/>
>>>     <medi:field xmltag="tax" matchOn="34-44"/>
>>>     <medi:field xmltag="date" matchOn="45-55"/>
>>>     </medi:segment>
>>>
>>> T.
>>>
>>>
>>> Bård Langöy wrote:
>>>  
>>>    
>>>      
>>>> Hi,
>>>>
>>>> Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?
>>>>
>>>> regards,
>>>> Bård
>>>> ________________________________________
>>>> Från: Tom Fennelly [[hidden email]]
>>>> Skickat: den 26 december 2009 08:44
>>>> Till: [hidden email]
>>>> Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request
>>>>
>>>> Hi Andy.
>>>>
>>>> Right, starting with the config is good.  You'll need to create a new
>>>> config version.
>>>>
>>>> Regards,
>>>>
>>>> T.
>>>>
>>>>
>>>> Andy Pemberton wrote:
>>>>  
>>>>    
>>>>      
>>>>        
>>>>> Thanks, Tom.
>>>>>
>>>>> That was actually my initial gut feeling, as it seems the EDI parser
>>>>> has most of what I need; it only lacks the fixed length field feature,
>>>>> really.
>>>>>
>>>>> I've actually got a configuration going that (so far) will build out
>>>>> the structure properly down to the field level.
>>>>>
>>>>> I'll take a look at extending the EDI cartridge this week, starting
>>>>> (as you suggested) with the configuration - I'll email back to this
>>>>> list for your thoughts.
>>>>>
>>>>> Thanks again,
>>>>> -Andy
>>>>>
>>>>>
>>>>> On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
>>>>> <mailto:[hidden email]>> wrote:
>>>>>
>>>>>     Hey Andy... see my last email on this thread... seems to me like
>>>>>     adaptation of the EDI Parser (and config) is the way forward for this.
>>>>>
>>>>>     T.
>>>>>
>>>>>
>>>>>     Andy Pemberton wrote:
>>>>>
>>>>>         The implementation guide for the specification itself is
>>>>>         licensed; so I've included a sample file.
>>>>>
>>>>>         The file structure looks like:
>>>>>
>>>>>         Header Record
>>>>>         First Report of Injury
>>>>>         First Report of Injury Companion Record
>>>>>         First Report of Injury
>>>>>         First Report of Injury Companion Record
>>>>>         Trailer Record
>>>>>
>>>>>         So it's 1 transmission, with 1 batch of records, 1 header, 4
>>>>>         transactions, and 1 trailer.
>>>>>
>>>>>         -Andy
>>>>>
>>>>>         On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
>>>>>         <mailto:[hidden email]> <mailto:[hidden email]
>>>>>         <mailto:[hidden email]>>> wrote:
>>>>>
>>>>>            Hm.
>>>>>
>>>>>
>>>>>            I would really like to see the specification for this. Just to
>>>>>            better grasp how the sequence flow is implemented. I will look
>>>>>            around if I can find an example file or something. Or could you
>>>>>            provide us with this Andy ? If the specs were licensed in
>>>>>         some way
>>>>>            maybe just an example-file will do for now..
>>>>>
>>>>>
>>>>>            Regards,
>>>>>
>>>>>            Bård
>>>>>
>>>>>
>>>>>         --
>>>>>         Andy Pemberton
>>>>>         www.andypemberton.com <http://www.andypemberton.com>
>>>>>         <http://www.andypemberton.com>
>>>>>
>>>>>         ------------------------------------------------------------------------
>>>>>
>>>>>         ---------------------------------------------------------------------
>>>>>         To unsubscribe from this list, please visit:
>>>>>
>>>>>            http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>>     ---------------------------------------------------------------------
>>>>>     To unsubscribe from this list, please visit:
>>>>>
>>>>>       http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Andy Pemberton
>>>>> www.andypemberton.com <http://www.andypemberton.com>
>>>>>    
>>>>>      
>>>>>        
>>>>>          
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>     http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>     http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>>  
>>>>    
>>>>      
>>>>        
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>     http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>  
>>>    
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>  
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>
>  

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: SV: SV: SV: SV: SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Tom Fennelly

Bård Langöy wrote:
Hi Tom,

Ok I think I understand... 

So then the matchOn value on component-level must always be the same as the value that you extract. You can in other words not check the value at position 11, and if that matches, extract the value from position 11-15. 

Hmm... alright. I don't want to be difficult about this :). 
hehehehe.... you never are Bard, so make sure you put me right if you think what I'm saying is not right.  That is how we end up with a better solution.  You have infinitely more experience of this type of thing!!!
I still like the idea of splitting up the functionality but I can also see  your point in that it might be easier for the user to configure. So if that is how we should do it then I like your attribute name (matchOn) best :). 
  
Well... lets not settle on anything for now.  What about something like this... splitting out the position and matchOn parts for fields components etc...
    <medi:segment segcode="HDR" xmltag="header" position="0-3">
    	<medi:field xmltag="order-id"  position="4-10"/>
    	<medi:field xmltag="status-code" position="11" matchOn="A"/>
    	<medi:field xmltag="net-amount" position="12-22"/>
    	<medi:field xmltag="total-amount" position="23-33"/>
    	<medi:field xmltag="tax" position="34-44"/>
    	<medi:field xmltag="date" position="45-55"/>
    </medi:segment>
I don't think you need the matchOn on the segment because the segcode value is what you're matching on.   So with the above, the segment is a match if 0-3 = "HDR" (segcode) and 11 = "A" (status-code).
Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [[hidden email]] 
Skickat: den 28 december 2009 16:30
Till: [hidden email]
Ämne: Re: SV: SV: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Ah ok Bard... so in my mind the matchOn/position would be used for  both 
matching and extraction. 

The parser could:

   1. Look at all of it's components, looking for position/matchOn
      attributes that contain explicit values (i.e. position="11='A'" Vs
      just position="11").
   2. Build an segment evaluate expression from all of these so as to
      perform a match for the segment
   3. Execute the expression on the segment text blob.  If the segment
      is a match, then it
          * uses the same matchOn/position range values to extract the
            values for the fields, components etc.

I think if you have the matchOn at the segment level only, then you 
probably end up with duplication by specifying the same ranges in both 
the matchOn on the segment, as well as some of the field/component elements.

Does that add up do you think?

T.

Bård Langöy wrote:
  
Hi Tom,

Ah ok... because to me they are logically different :) I think I am just bad at explaining myself here. 

So, what I mean is that at Segment level the matchOn attribute is used to tell the EDIParser at what position the segcode is located. I.e. there are no value extraction at this point... but at the components level the position attribute is used to actually used to extract the value at the given position, so there will be no matching at that point. 

But I have no strong opinions about this... I just think that the operations at segment level and component level are different. But if you think it will be easier for users to have the same attribute I say we go for that ! 


Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [[hidden email]] 
Skickat: den 28 december 2009 15:03
Till: [hidden email]
Ämne: Re: SV: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

:)  are they they same, except the attribute on the field element is 
named "position" Vs "matchOn"?  I'm OK with naming them "position", but 
I would also rename the matchOn attribute on the segment to "position" 
too... I think having them different would be quite confusing (at least 
to me, they are logically the same thing).

T.

Bård Langöy wrote:
  
    
Hi Tom,

Yes, what I had in mind is that it is only the segment element that needs the matchOn attribute. If the line matches then it is time to extract the values specified in the field-components. And for extracting those values you need to know the location/position of the values since there are no delimiters. And it is not possible to do a matchOn since the value can vary. So I think that we think alike but the matchOn could be a bit confusing since we are not doing a match in this case but actually a value-extraction at the given position.

So an example of this config would be something like:

<medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
  
    
      
    	<medi:field xmltag="order-id"  position="4-10"/>
    	<medi:field xmltag="status-code" position ="11='A'"/>
    	<medi:field xmltag="net-amount" position ="12-22"/>
    	<medi:field xmltag="total-amount" position ="23-33"/>
    	<medi:field xmltag="tax" position="34-44"/>
    	<medi:field xmltag="date" position ="45-55"/>
    </medi:segment>
    
      
        
What do you think ?

Regards,
Bård


-----Ursprungligt meddelande-----
Från: Tom Fennelly [[hidden email]] 
Skickat: den 28 december 2009 09:42
Till: [hidden email]
Ämne: Re: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Can you show an example Bard?

So in what I was suggesting there, the segment would be matched based on 
an effective accumulation of the matchOn configs for the components of 
the segment i.e. code that reads something like "if  chars 0-3 = 'HDR' 
and  char 11 = 'A'".

I thought that read OK in the config (easy for the user to see how 
individual fields etc are being matched + no duplication between the 
matchOn on the segment and the start/end attribute vals), but I 
obviously need to see what you have in mind Bard.

T.

Bård Langöy wrote:
  
    
      
Hi,

But should we not separate the matchOn attribute from the actual value extraction ? 

So, on segment level we have the matchOn that does the actual match. On each "leaf" component, which should be only fields in Andy's case, we should have something like a startPos and endPos or something like that. 

Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [[hidden email]] 
Skickat: den 28 december 2009 08:28
Till: [hidden email]
Ämne: Re: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Not sure Bard.... I thought there'd be one at each component level in 
the model e.g....

    <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
    	<medi:field xmltag="order-id"  matchOn="4-10"/>
    	<medi:field xmltag="status-code" matchOn="11='A'"/>
    	<medi:field xmltag="net-amount" matchOn="12-22"/>
    	<medi:field xmltag="total-amount" matchOn="23-33"/>
    	<medi:field xmltag="tax" matchOn="34-44"/>
    	<medi:field xmltag="date" matchOn="45-55"/>
    </medi:segment>

T.


Bård Langöy wrote:
  
    
      
        
Hi,

Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?

regards,
Bård
________________________________________
Från: Tom Fennelly [[hidden email]]
Skickat: den 26 december 2009 08:44
Till: [hidden email]
Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request

Hi Andy.

Right, starting with the config is good.  You'll need to create a new
config version.

Regards,

T.


Andy Pemberton wrote:
  
    
      
        
          
Thanks, Tom.

That was actually my initial gut feeling, as it seems the EDI parser
has most of what I need; it only lacks the fixed length field feature,
really.

I've actually got a configuration going that (so far) will build out
the structure properly down to the field level.

I'll take a look at extending the EDI cartridge this week, starting
(as you suggested) with the configuration - I'll email back to this
list for your thoughts.

Thanks again,
-Andy


On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
[hidden email]> wrote:

    Hey Andy... see my last email on this thread... seems to me like
    adaptation of the EDI Parser (and config) is the way forward for this.

    T.


    Andy Pemberton wrote:

        The implementation guide for the specification itself is
        licensed; so I've included a sample file.

        The file structure looks like:

        Header Record
        First Report of Injury
        First Report of Injury Companion Record
        First Report of Injury
        First Report of Injury Companion Record
        Trailer Record

        So it's 1 transmission, with 1 batch of records, 1 header, 4
        transactions, and 1 trailer.

        -Andy

        On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
        [hidden email] <[hidden email]
        [hidden email]>> wrote:

           Hm.


           I would really like to see the specification for this. Just to
           better grasp how the sequence flow is implemented. I will look
           around if I can find an example file or something. Or could you
           provide us with this Andy ? If the specs were licensed in
        some way
           maybe just an example-file will do for now..


           Regards,

           Bård


        --
        Andy Pemberton
        www.andypemberton.com <http://www.andypemberton.com>
        <http://www.andypemberton.com>

        ------------------------------------------------------------------------

        ---------------------------------------------------------------------
        To unsubscribe from this list, please visit:

           http://xircles.codehaus.org/manage_email



    ---------------------------------------------------------------------
    To unsubscribe from this list, please visit:

      http://xircles.codehaus.org/manage_email





--
Andy Pemberton
www.andypemberton.com <http://www.andypemberton.com>
    
      
        
          
            
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  
    
      
        
          
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  
    
      
        
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  
    
      
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  
    

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  
Reply | Threaded
Open this post in threaded view
|

Re: SV: SV: SV: SV: SV: Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

pembertona
Watching the conversation here; I like the proposed configuration Bard supplied and this is very much inline with what I was envisioning.

In my case, I'd use:
- regular-expression based SEGCODE matching
- position attribute matching at the field level (so matchOn would be optional)

-AP

On Mon, Dec 28, 2009 at 1:10 PM, Tom Fennelly <[hidden email]> wrote:

Bård Langöy wrote:
Hi Tom,

Ok I think I understand... 

So then the matchOn value on component-level must always be the same as the value that you extract. You can in other words not check the value at position 11, and if that matches, extract the value from position 11-15. 

Hmm... alright. I don't want to be difficult about this :). 
hehehehe.... you never are Bard, so make sure you put me right if you think what I'm saying is not right.  That is how we end up with a better solution.  You have infinitely more experience of this type of thing!!!

I still like the idea of splitting up the functionality but I can also see  your point in that it might be easier for the user to configure. So if that is how we should do it then I like your attribute name (matchOn) best :). 
  
Well... lets not settle on anything for now.  What about something like this... splitting out the position and matchOn parts for fields components etc...
    <medi:segment segcode="HDR" xmltag="header" position="0-3">
    	<medi:field xmltag="order-id"  position="4-10"/>
    	<medi:field xmltag="status-code" position="11" matchOn="A"/>
    	<medi:field xmltag="net-amount" position="12-22"/>
    	<medi:field xmltag="total-amount" position="23-33"/>
    	<medi:field xmltag="tax" position="34-44"/>
    	<medi:field xmltag="date" position="45-55"/>
    </medi:segment>
I don't think you need the matchOn on the segment because the segcode value is what you're matching on.   So with the above, the segment is a match if 0-3 = "HDR" (segcode) and 11 = "A" (status-code).

Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [[hidden email]] 
Skickat: den 28 december 2009 16:30
Till: [hidden email]
Ämne: Re: SV: SV: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Ah ok Bard... so in my mind the matchOn/position would be used for  both 
matching and extraction. 

The parser could:

   1. Look at all of it's components, looking for position/matchOn
      attributes that contain explicit values (i.e. position="11='A'" Vs
      just position="11").
   2. Build an segment evaluate expression from all of these so as to
      perform a match for the segment
   3. Execute the expression on the segment text blob.  If the segment
      is a match, then it
          * uses the same matchOn/position range values to extract the
            values for the fields, components etc.

I think if you have the matchOn at the segment level only, then you 
probably end up with duplication by specifying the same ranges in both 
the matchOn on the segment, as well as some of the field/component elements.

Does that add up do you think?

T.

Bård Langöy wrote:
  
Hi Tom,

Ah ok... because to me they are logically different :) I think I am just bad at explaining myself here. 

So, what I mean is that at Segment level the matchOn attribute is used to tell the EDIParser at what position the segcode is located. I.e. there are no value extraction at this point... but at the components level the position attribute is used to actually used to extract the value at the given position, so there will be no matching at that point. 

But I have no strong opinions about this... I just think that the operations at segment level and component level are different. But if you think it will be easier for users to have the same attribute I say we go for that ! 


Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [[hidden email]] 
Skickat: den 28 december 2009 15:03
Till: [hidden email]
Ämne: Re: SV: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

:)  are they they same, except the attribute on the field element is 
named "position" Vs "matchOn"?  I'm OK with naming them "position", but 
I would also rename the matchOn attribute on the segment to "position" 
too... I think having them different would be quite confusing (at least 
to me, they are logically the same thing).

T.

Bård Langöy wrote:
  
    
Hi Tom,

Yes, what I had in mind is that it is only the segment element that needs the matchOn attribute. If the line matches then it is time to extract the values specified in the field-components. And for extracting those values you need to know the location/position of the values since there are no delimiters. And it is not possible to do a matchOn since the value can vary. So I think that we think alike but the matchOn could be a bit confusing since we are not doing a match in this case but actually a value-extraction at the given position.

So an example of this config would be something like:

<medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
  
    
      
    	<medi:field xmltag="order-id"  position="4-10"/>
    	<medi:field xmltag="status-code" position ="11='A'"/>
    	<medi:field xmltag="net-amount" position ="12-22"/>
    	<medi:field xmltag="total-amount" position ="23-33"/>
    	<medi:field xmltag="tax" position="34-44"/>
    	<medi:field xmltag="date" position ="45-55"/>
    </medi:segment>
    
      
        
What do you think ?

Regards,
Bård


-----Ursprungligt meddelande-----
Från: Tom Fennelly [[hidden email]] 
Skickat: den 28 december 2009 09:42
Till: [hidden email]
Ämne: Re: SV: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Can you show an example Bard?

So in what I was suggesting there, the segment would be matched based on 
an effective accumulation of the matchOn configs for the components of 
the segment i.e. code that reads something like "if  chars 0-3 = 'HDR' 
and  char 11 = 'A'".

I thought that read OK in the config (easy for the user to see how 
individual fields etc are being matched + no duplication between the 
matchOn on the segment and the start/end attribute vals), but I 
obviously need to see what you have in mind Bard.

T.

Bård Langöy wrote:
  
    
      
Hi,

But should we not separate the matchOn attribute from the actual value extraction ? 

So, on segment level we have the matchOn that does the actual match. On each "leaf" component, which should be only fields in Andy's case, we should have something like a startPos and endPos or something like that. 

Regards,
Bård

-----Ursprungligt meddelande-----
Från: Tom Fennelly [[hidden email]] 
Skickat: den 28 december 2009 08:28
Till: [hidden email]
Ämne: Re: SV: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length question/feature request

Not sure Bard.... I thought there'd be one at each component level in 
the model e.g....

    <medi:segment segcode="HDR" xmltag="header" matchOn="0-3">
    	<medi:field xmltag="order-id"  matchOn="4-10"/>
    	<medi:field xmltag="status-code" matchOn="11='A'"/>
    	<medi:field xmltag="net-amount" matchOn="12-22"/>
    	<medi:field xmltag="total-amount" matchOn="23-33"/>
    	<medi:field xmltag="tax" matchOn="34-44"/>
    	<medi:field xmltag="date" matchOn="45-55"/>
    </medi:segment>

T.


Bård Langöy wrote:
  
    
      
        
Hi,

Yes, this sounds like an EDI extension to me too. So then we only allow one mathOn in the config right ?

regards,
Bård
________________________________________
Från: Tom Fennelly [[hidden email]]
Skickat: den 26 december 2009 08:44
Till: [hidden email]
Ämne: Re: [milyn-dev] Re: SV: [milyn-user] SV: Smooks EDI fixed length  question/feature request

Hi Andy.

Right, starting with the config is good.  You'll need to create a new
config version.

Regards,

T.


Andy Pemberton wrote:
  
    
      
        
          
Thanks, Tom.

That was actually my initial gut feeling, as it seems the EDI parser
has most of what I need; it only lacks the fixed length field feature,
really.

I've actually got a configuration going that (so far) will build out
the structure properly down to the field level.

I'll take a look at extending the EDI cartridge this week, starting
(as you suggested) with the configuration - I'll email back to this
list for your thoughts.

Thanks again,
-Andy


On Thu, Dec 24, 2009 at 3:54 AM, Tom Fennelly <[hidden email]
[hidden email]> wrote:

    Hey Andy... see my last email on this thread... seems to me like
    adaptation of the EDI Parser (and config) is the way forward for this.

    T.


    Andy Pemberton wrote:

        The implementation guide for the specification itself is
        licensed; so I've included a sample file.

        The file structure looks like:

        Header Record
        First Report of Injury
        First Report of Injury Companion Record
        First Report of Injury
        First Report of Injury Companion Record
        Trailer Record

        So it's 1 transmission, with 1 batch of records, 1 header, 4
        transactions, and 1 trailer.

        -Andy

        On Wed, Dec 23, 2009 at 3:42 AM, Bård Langöy <[hidden email]
        [hidden email] <[hidden email]
        [hidden email]>> wrote:

           Hm.


           I would really like to see the specification for this. Just to
           better grasp how the sequence flow is implemented. I will look
           around if I can find an example file or something. Or could you
           provide us with this Andy ? If the specs were licensed in
        some way
           maybe just an example-file will do for now..


           Regards,

           Bård


        --
        Andy Pemberton
        www.andypemberton.com <http://www.andypemberton.com>
        <http://www.andypemberton.com>

        ------------------------------------------------------------------------

        ---------------------------------------------------------------------
        To unsubscribe from this list, please visit:

           http://xircles.codehaus.org/manage_email



    ---------------------------------------------------------------------
    To unsubscribe from this list, please visit:

      http://xircles.codehaus.org/manage_email





--
Andy Pemberton
www.andypemberton.com <http://www.andypemberton.com>
    
      
        
          
            
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  
    
      
        
          
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  
    
      
        
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  
    
      
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  
    
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



  



--
Andy Pemberton
www.andypemberton.com
123