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

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

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: roberto@javest.com
Date: Thu, December 14, 2006 11:39 am
To: "David RR Webber (XML)" <david@drrw.info>
Cc: roberto@javest.com, ubl-dev@lists.oasis-open.org,
stephen.gould@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: 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
>
>
> ---------------------------------------------------------------------
> 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