Quoted text is from <D7DEA8A4DB13D511A8BB0090273AD8D40F01DD@DNEXCHANGE2>
, by Murray, John <[EMAIL PROTECTED]>
>The solution you select should offer you the flexibility to meet your
>current needs plus adapt to any changes in those needs in the future. Buy
>into a low end solution that limits the output format and you get to go
>through the buying process all over again and all too soon! Flexibility in
>selecting the proprietary format is highly desireable.
I think we may be arguing along slightly different lines. For me the
mapping process consists of describing how data is moved between two
different models: On one side the application import/export file(s) /
database tables, and on the other the hierarchical structure of an EDI
transaction. Whilst most clients understand their data model well, the
EDI structure can be intimidating to those not familiar with it. Using
an EDIFACT example, if I want to import the fax number for the buyers
technical guru from an EDI message, I need to map between wherever my
application interface has that parameter and a COM segment with an FX
qualifier after a CTA segment with an AT qualifier after a NAD segment
with a BY qualifier. It is a little too elaborate to be convenient.
It is easier to map to a field called %buyer_tech_faxno in an
intermediary file format. In fact the identification of a parameter in
your application as %buyer_tech_faxno *is* the mapping. The nasty
resolution to NAD/BY -> CTA/AT -> COM/FX is done by a fixed secondary
mapping which your friendly EDI system vendor has already set up for
you, and you need not know anything about.
This doesn't impact on a mappers capability of dealing with the variety
of forms of application side data model; it is just simplifying the
perceived complexity of the EDI side. This means that mapping can be
performed successfully by those not wholly immersed (pickled might be a
better word) in the niceties of the EDI transaction itself.
My fans (my Mother, Bless her) will probably have guessed by now that I
am riding a favourite hobby horse disguised by a different saddle cloth.
"This intermediary file format is just a clumsy implementation of a
repository concept" they say, scathingly. "Wouldn't you rather have a
*real* repository implemented in your software?" - to which I can only
reply, ecstatically, "Yes, please!".
Regards
Chris
--
Chris Johnson +44 (0)20 8501 1490 (home)
EDIMatrix Ltd +44 (0)20 8559 2454 (work)
+44 (0)20 8559 2497 (fax)
http://www.edimatrix.co.uk
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
