Re: [ebxml-mktg-sc] FW: WebServices.Org - The Web Services Industry Portal - New XML e-business model s

[David RR Webber - XML ebusiness <Gnosis_@compuserve.com>]

Mark,

I did not see your attachment before.  Sometimes these get "missed"
because of weird / no MIMEtype labelling in the email headers.

Anyway - now I can "see" this - its even more disheartening!  I had
merely based my comments on the original CICA publically 
available papers from DISA.

What I always find tough is that you work on specifications - you
make them freely available - you ask for participation - but there's
still parallel universes spawning left and right - and worse - where
problems you have already solved are being perpetuated 
because of false trails and missed understanding!

Alot of points in cases are contained in Bob's paragraphs below.
The OASIS BCM work is already ontology first - in providing means
to collect business templates for re-use and semantics and patterns,
and ebXML Registry is there to collect these into dictionaries, 
classifications and encyclopedias.  DISA even has their own
DRIve effort aimed at implementing this - but has ignored it.

The OASIS CAM work solves all the "mapping problems" 
described and attributed to using mixes of EDI and XML.
So much so - that its almost painful to see people making
assumptions like : 
> I observe that, as difficult as it is to define data mapping into and 
> out of  in-house operations within the traditional EDI syntax may be, 
> the introduction of XML syntax will, espcially in the short term, make 
> matters worse.   For example, the temptation to 'extend' common 
> transactions to suit specific company needs will not face the reality 
> of a standard EDI transaction set that doesn't support such an 
> extension. 

The work by OAGIS on their BODs has already shown how to solve
this elegantly - and adding CAM to this - merely takes it to the next
level - of being able to share implementation patterns within an
industry and community of interest - and manage local extensions
effectively.

I think this just reinforces my original view that X12 is taking a 
path up a blind-alley and not solving what CICA points out
should be addressed.

Thanks, DW.
===========================================================
Message text written by Monica Martin
>>  -----Original Message-----
> *From:  * Miller, Robert (GXS) 
> *Sent:  * Tuesday, August 12, 2003 3:16 PM
> *Subject:       * RE: WebServices.Org - The Web Services Industry 
> Portal - New XML e-business model s
>
> Mark,
>
> _CICA enhances semantic understanding currently not well addressed in 
> the evolving UN/CEFACT specifications related to document assembly._  
> I know UN/CEFACT will review this work, but I don't know if they will 
> integratet its principles into theri ongoing work effort.  Articles 
> such as this one certainly improve the chances UN/CEFACT will pay 
> serious attention to this work.
>
> Would that it did all that the article suggests it does, but much of 
> the article speaks of a detailed level of semantic knowledge which 
> neither X12 nor DISA as addressed from a data collection and storage 
> viewpoint.  That's not to say these bodies won't eventually reach that 
> level of sophistication.  There is an effort underway in OASIS, for 
> example, to apply ontologic methodology to the data units that make up 
> a business transaction, and so provide a means to capture detailed 
> semantic information in an systematic manner, and to organize the 
> information in a manner that aids both document and application 
> implementation.  Think of the Dewey Decimal system for organizing 
> library books, and of encyclopedias for providing an organized set of 
> information on a given subject.
>
> As I previously mentioned in an earlier Email, there is an ongoing 
> controversy both inside and outside the X12 body about the 
> appropriateness of the X12 effort, given the ongoing work in 
> UN/CEFACT.  I am quite convinced that the end result of the X12 effort 
> will not be a separate, UN/CEFACT incompatible X12 standard for XML 
> messages.  Rather, I believe that X12 will achieve its need to more 
> closely control semantic content of messages witin the evolving 
> UN/CEFACT architecture, and will in time adopt that architecture as 
> the standard.    
>
> Some of the work X12 is currently undertaking, especially as relates 
> to XML syntax to represent messages designed using the new 
> architectural principles, seems unlikely to my mind of gaining 
> significant support.  Of course, syntax is where the rubber meets the 
> road, and understandably, businesses don't want to pay for multiple 
> sets of tires.
>
> As you well know, some companies already use XML to exchange business 
> data, though none of these exchanges could be considered standard 
> conformant, since such standards have yet to be defined.  I would 
> expect where such usage is among larger groups that these groups will 
> find opportunities to achieve conformance with international standards. 
>
> I observe that, as difficult as it is to define data mapping into and 
> out of  in-house operations within the traditional EDI syntax may be, 
> the introduction of XML syntax will, espcially in the short term, make 
> matters worse.   For example, the temptation to 'extend' common 
> transactions to suit specific company needs will not face the reality 
> of a standard EDI transaction set that doesn't support such an 
> extension.  It is 'easier' to mutually agree to extend a schema to 
> meet  perceived (or real) business needs than to go through a formal 
> standards-based process to meet that need.  Over time the cumulative 
> effect of such informal extensions could lead to a return of chos to 
> eBusiness transactions.
>
> Befroe closing, I would like to observe that many existing X12 and 
> UN/CEFACT transaction sets are already well designed, are meeting 
> business needs, adn are more cost efective to produce and transmit 
> than would be any XML replacement.  I therefore expect traditonal EDI 
> volume will continue to increase over the next several years.  Whether 
> the volume transported via VANs will increase or decrease, and what 
> value added services will rise or fall in improtance I am unable to 
> predict with any certainty. I do expect that their will arise within 
> the EDI Translation umbrella a need to perform endpoint conversions of 
> EDI formatted data into and out of XML formatted data (or at least 
> into and out of  XML interpretor interface format) used to exchange 
> data with XML-savvy application programs (e.g., with XSLT, XFORMS, 
> etc.).  It would be impractical to reproduce these versatile tools to 
> interface directly with EDI syntax, since they are generic XML-based 
> tools  designed to interoperate with modern, highly complex, personal 
> computer operating environments.
>
> Cheers,
>              Bob
>
<