> 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.
>
We do somewhat the same thing with many of our maps, due to the complexity
of the interfaces that we deal with. Most of our mappings go to a "generic"
intermediate map, which takes a simplistic application UDF as an input file
and generates a (much more complex) application UDF file that gets sent to
the application gateway. Based upon our naming standards, where we use
"UGENE" as part of the file name to indicate a "generic" map, we
(semi-)fondly call these maps "Eugene" maps.
> 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.
>
I vote "Pickled." It also might be described accurately as "embalmed."
> 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!".
>
And what would you tender as an example of a *real* repository?
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
