Details
-
Type:
New Feature
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: Smooks v1.6
-
Component/s: EDI
-
Labels:None
-
Number of attachments :
Description
- Allowing wildcard segment codes ("segcode").
- Making the "xmltag" attribute optional on the segment element. In this case the parser would simply map the segment code to the xmltag.
- Something on a segment config (what would we call this??) that simply tells the parser that the the mapping model will not be defining the field mappings and that it should just accept all fields present in the segment and name them "field.0", "field.1" etc. Perhaps this behavior could simply be inferred if no field mappings are defined??
So, if you then had the following "default" mapping model for all your messages:
<?xml version="1.0" encoding="UTF-8"?> <medi:edimap xmlns:medi="http://www.milyn.org/schema/edi-message-mapping-1.0.xsd"> <medi:description name="Mirth Default EDI to XML Maping Model" version="1.0" /> <medi:delimiters segment=" " field="*" component="^" sub-component="~" /> <medi:segments xmltag="edi-message"> <!-- segcode="*": Allow any Segment code. xmltag note defined: Map the code to the XML tag name. maxOccurs="-1": Allow any number of them. mapAllFields="true": Map all segment fields, even if undefined. Undefined fields are mapped to "field.x". --> <medi:segment segcode="*" maxOccurs="-1" mapAllFields="true" /> </medi:segments> </medi:edimap>
So, the following message...
MSG1*v1*v2*v3*v4
MSG2*w1*w2*w3
MSG3*x1*x2*x3*x4*x5
Would generate the following XML (via SAX events of course)...
<edi-message> <MSG1> <field.0>v1<field.0> <field.1>v2<field.1> <field.2>v3<field.2> <field.3>v4<field.3> </MSG1> <MSG2> <field.0>w1<field.0> <field.1>w2<field.1> <field.2>w3<field.2> </MSG2> <MSG3> <field.0>x1<field.0> <field.1>x2<field.1> <field.2>x3<field.2> <field.3>x4<field.3> <field.3>x5<field.3> </MSG3> </edi-message>