RE: [ubl-dev] Time to review Edifact NAD format ?

["David RR Webber \(XML\)" <david@drrw.info>]

Roberto, 

There in lies the rub - EDI did try in the past to fix this - it was
called IMPDEF and was adopted by X12 and EDIFACT.  20 developers signed
up to use it - but only 2 did.

The idea behind IMPDEF was to move away from paper documents and
spreadsheets specifying the "IC" Implementation Convention - between 2
partners - that is a specialization of the industry "IG" Implementation
Guide for the EDI transactions they picked.  So IMPDEF is an EDI message
about an EDI message!  That allows automated descriptions and
processing.  Trouble is IMPDEF is arcane and tough to maintain and
debug.

Enter XML.  

The W3C pitched XML as being self-describing and human friendly - and
then they created XSD which they describe as machine processable only,
and arcane... There's a pattern here somewhere, no? ; -)

Help however is at hand - the OASIS CAM TC - which I coincidently chair
- has a template method that allows you to contextually describe the
interchange with your partner - so while XSD allows you to define all
possible structural permitations you may ever receive - (the "IG") -
CAM templates allow you to describe the "IC" for your particular use
and partner needs.  CAM templates are designed to be easy to read and
edit by humans!

The latest CAM v1.1 is implemented as open source - and there now is an
Eclipse editor tool that allows you to quickly create a CAM validation
template for any sample XML. http://www.jcam.org.uk 

Enjoy, DW

"The way to be is to do" - Confucius (551-472 B.C.)
 

 -------- Original Message --------
Subject: Re: [ubl-dev] Time to review Edifact NAD format ?
From: roberto@javest.com
Date: Thu, December 14, 2006 9:52 am
To: stephen.gould@halisa.net
Cc: ubl-dev@lists.oasis-open.org

Hello developers,

the C058 is for unstructured addresses

the other composites/elements are for a formatted (structured) address.

As a programmer I would prefere to deal with the "structured" choice,
but
b2b depends from agreements and these have been completely unconstrained
in the past.

Usually is is considered an agreement violation when a partner change
EDI
message mappings without notice, thus when we send the address using the
unstructured way the partner is prepare to receive it.

EDIFact is not suitable for unexpected EDI messages from unknown
partners
without a specific agreement, as this practise will results into 50% or
more exceptions.

The e-commerce or cyber-commerce should fix these unconstrained
transactions in the future... it's time to speak UBL and ebXML ;-)

Best regards

UBL ITLSC
co-chair
Roberto Cisternino


> EDI is proving to be a disaster around the world mainly because the
> Standards were formulated over 20 years ago with the driving force being
> to reduce Purchasing costs not facilitate Trade
>
> EDIFACT was first release in 1987 and the format has not been
> revised hence the normal business problem of unclear instruction
> results in mayhem.
>
> There are two address formats in the NAD Data Segment without
> any directions to stipulate when each format should be used
>
> With the advent of XML and the Internet perhaps it is time to have very
> clear instructions when to use each format or just reduce it to one
> format only
>
> A TECHNICAL PROBLEM WITH MULTIPLE ADDRESS FORMATS
>
> The OIC Expert IT eCommittee formed to resolve the single XML address
> for ASA 4590 has initially confirmed that the Complex version can replace
> the Simplex version to establish a single XML Address format
>
> It now appears that UN/CEFACT (EDIFACT) has the same problem with
> different options in the Name and Address (NAD) Data Segment for each
> Trade Document
>
> Whilst I appreciate you will not have reviewed the details of the data
> elements and data components of UN/CEFACT, here is a link to the
> "NAD" Data Segments and three eTrade documents downloaded from the
> Australia TradeGate Importer/Exporter Web Site
> http://www.oic.org/z/XZIG/UNCEFACT/ZXAAECR1.htm
>
> As you can see there will be much confusion as to whether software
> developers should use Data Element CO58 or CO80 and CO59.
>
> However the main problem is that software will have to be written
> to check which whether "CO58 has been used" or whether "CO80 has
> been used thru to 3207"
> http://www.halisa.net/R/EDIFACT/edieraa1.htm
>
> B PORT OF MELBOURNE EOI 13110
>
> The Government Responses to Questions to the Port of Melbourne
> eCommunity PoMC EOI 13110 indicates there is much confusion from
> Government responses on the use of Ecommerce Standards
> http://www.oic.org/z/XZIG/tdr/BCbAAWL7/BCbAAWQ1.htm#Ah
>
> It is appropriate UN/CEFACT to clarify the issues prior to the RFT being
> published as EOI 13110 states all importers and exporters must use
> EDIFACT.
>
> C UN/CEFACT SUPPORT FOR TRADE FACILITATION
>
> The Mission Statement of UN/CEFACT states it "supports activities
> dedicated to improving the ability of business, trade and administrative
> organizations, from developed, developing and transitional economies,
> to exchange products and relevant services effectively"
> http://www.oic.org/z/FZIG/AUJS/p/C/1UCAAEB1.htm
>
> In Sep 2004 you and I reviewed your draft eCommerce Trade Strategy
> for the Asia Pacific Region
> http://www.oic.org/A/U/
>
> On reviewing that Strategy again, I believe the key issue for Trade
> Facilitation is the single address format within the "NAD" Data Segment
> for all eTrade Documents.
>
> Hence I believe the recommendations on the AS 4590 Standard will be
> pertinent to UN/CEFACT.
>
> NEXT STEPS
>
> What do you think ?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>


Roberto Cisternino

---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org