9 messages in org.oasis-open.lists.ubl-devRE: [ubl-dev] Time to review Edifact ...| From | Sent On | Attachments |
|---|---|---|
| Stephen GOULD | Dec 14, 2006 4:57 am | |
| robe...@javest.com | Dec 14, 2006 6:51 am | |
| David RR Webber (XML) | Dec 14, 2006 7:26 am | |
| David RR Webber (XML) | Dec 14, 2006 7:48 am | |
| robe...@javest.com | Dec 14, 2006 8:40 am | |
| David RR Webber (XML) | Dec 14, 2006 8:55 am | |
| Stephen GOULD | Dec 15, 2006 4:09 pm | |
| Fulton Wilcox | Dec 15, 2006 6:23 pm | |
| Stephen GOULD | Dec 18, 2006 8:33 pm |
| Subject: | RE: [ubl-dev] Time to review Edifact NAD format ? | |
|---|---|---|
| From: | David RR Webber (XML) (dav...@drrw.info) | |
| Date: | Dec 14, 2006 8:55:48 am | |
| List: | org.oasis-open.lists.ubl-dev | |
Roberto,
Yes - this is the crux. Developing that tutorial is needed.
Today the business decisions in EDI are being made by programmers - who create a complex wiring ball that only they can maintain. Also - XML allows better fit to purpose - while in EDI the accepted practice is to wrongly overload all kinds of elements out of expedience - and use code values as a band-aid - the EDI equivalent of an element / attribute?!?
We are striving to create a better mouse trap - where the business rules can be shared and understood by most of the stakeholders in the process - not a select few.
Sacha Schlegel has given me some ideas for a 'screencast' with jCAM that I need to do over the holiday break.
Inherently out of that process should be wider sharing of those common rule components. It's the seemingly simple parts - like the <include/> statements - that reference common definitions - that can be drivers in building a community of practice.
I like what Sacha and Stephen have done with their resource site for UBL schemas - and I plan to contribute CAM templates to that as we develop them in 2007...but obviously anyone else can also make templates and do that as well!
Thanks, 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: robe...@javest.com Date: Thu, December 14, 2006 11:39 am To: "David RR Webber (XML)" <dav...@drrw.info> Cc: robe...@javest.com, ubl-...@lists.oasis-open.org, step...@halisa.net
Thanks David, I know about CAM, I am starting using JCAM.
My main experience on EDI is as an EDI team member not as developer, I see a big difference from what is standardized and what is used in the reality. UN/EDIFact has many users but most are using old directories, noone or few based their transaction on a specific agreement, EDI Translator's message mappings are the real agreement between customers at the moment. Many partners promised to implement UN/Edifact using specific guidelines like SMDG and ITIGG for shipping and transport, but there are thousand exceptions to this, expecially about code lists, that is one of the biggest problems.
We all hope that UBL, CAM, genericodes will let EDI solve interoperability problems.
I personally think we'll have a wider adoption of UBL over EDIFact due to its internationalization, also XML validation will stop many past problems.
I am a little surprised that very few messages about strict UBL development appears here.
I would like to see soon a base tutorial to introduce UBL use together ebXML.
Thanks for your replies
Roberto Cisternino
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: robe...@javest.com Date: Thu, December 14, 2006 9:52 am To: step...@halisa.net Cc: ubl-...@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 ?
Roberto Cisternino
Roberto Cisternino