Is the UBL group in OASIS in this space too? As far as I have been able
to figure out they may be more in the business of making a framework to
put such information into -- but it seems to me that the UN/CEFACT work
has something of that flavor, too. Whether we are talking about
competing or harmonizing frameworks is utterly unclear to me.
-----Original Message-----
From: Anders W. Tell [mailto:opensource@toolsmiths.se]
Sent: Wednesday, September 24, 2003 5:38 AM
To: www-ws-arch@w3.org
Cc: Ugo Corda
Subject: Re: Genuine interoperability & the tower of Babel
Hi Ugo,
One of the initiatives is the Core Components work done by UN/CEFACT
Techologies and Methodologies group.
<http://webster.disa.org/cefact-groups/tmg/> (site is down for the
moment) See download/general menu for downloadable documents.
This groups work with technology neutral semantic interoperability with
well defined mappings to EDIFACT and XML.
/anders
Ugo Corda wrote:
>I recently came across an initiative that seems to address this type of
>issues. It's called Universal Data Element Framework (or UDEF - see
>http://www.udef.org/). According to its Web page, "the objective of the
>UDEF is to provide a means of real-time identification for semantic
>equivalency, as an attribute to data elements within e-business
>document and integration formats".
>
>If somebody else knows of similar initiatives, it would be nice to
>mention them in our document.
>
>Ugo
>
>
>
>>-----Original Message-----
>>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
>>Behalf Of Cutler, Roger (RogerCutler)
>>Sent: Monday, September 22, 2003 7:26 PM
>>To: Champion, Mike; Frank McCabe; www-ws-arch@w3.org
>>Subject: RE: Genuine interoperability & the tower of Babel
>>
>>
>>
>>I agree with Mike's answer -- but I also agree with Frank's analysis.
>>Three or five years ago we sort of thought that the XML bandwagon was
>>going to solve this by industry-wide efforts to define common formats
>>for core data. I know this very well because I wrote various program
>>plans based on this assumption that I now either live with or modify
>>accordingly. Whether this did not happen because it is very difficult,
>>or whether it didn't happen because there was no analogy to MS/IBM/BEA
>>to force the process is probably not relevant -- it has not happened.
>>
>>This is a shame, but we must somehow struggle on.
>>
>>So, Frank, granted that this is a problem, and an expensive one, just
>>what do you propose doing about it? Weeping, gnashing our teeth and
>>rending our garments is probably indicated, but once we have done all
>>that, do you have any other suggestions?
>>
>>I would personally not be very receptive if your suggestions involved
>>starting over from square one in the WSA.
>>
>>-----Original Message-----
>>From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
>>Sent: Monday, September 22, 2003 9:10 PM
>>To: Frank McCabe; www-ws-arch@w3.org
>>Subject: RE: Genuine interoperability & the tower of Babel
>>
>>
>>
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: Frank McCabe [mailto:frankmccabe@mac.com]
>>>Sent: Monday, September 22, 2003 9:40 PM
>>>To: www-ws-arch@w3.org
>>>Subject: Genuine interoperability & the tower of Babel
>>>
>>>
>>>
>>
>>
>>
>>>The tower of Babel referred to above is the huge number of
>>>application-specific systems that can't leverage each other because
>>>of trivial but lethal incompatibilities. There has to be a better
>>>way.
>>>
>>>Before we look at solutions, it is helpful to see that there is a
>>>problem. Is this analysis off the mark, and if so, why?
>>>
>>>
>>I'm not sure. There's a danger in taking things one step at a time if
>>the steps don't lead anywyhere, e.g. climing a tree as the first step
>>to get to the moon. But there's also a danger in saying that it does
>>no good to get to the moon if you really really want to reach the
>>stars.
>>
>>Let's look at the world of 15 years ago vs the world of
>>today, the near
>>term future, and the future we want to shape. 15 years ago a typical
>>computer simply could not communicate with another computer chosen at
>>random, except very inefficiently and with all sorts of human
>>intervention (remember zmodem etc.?). That's because there
>>was no common
>>wire level protocol or addressing scheme (in widespread use
>>anyway). 10
>>years ago the Internet solved that problem at the lowest level for at
>>least the typical commercial/university system, but there
>>wasn't much in
>>the way of common data formats or application-level
>>protocols. 5 years
>>ago HTTP and HTML solved those problems for human-readable
>>text, but not
>>for machine-machine interaction without human intervention. Today XML
>>and SOAP/WSDL are providing the framework for machine-machine
>>interaction, but there are a bazillion details such as transactions,
>>choreography, security, etc. etc. etc. that have to be worked
>>out in an
>>ad hoc way. In 5 year we'll presumably have this stuff standardized,
>>BUT THEN we will still face the problems that Frank is
>>talking about.
>>
>>So, I think that the WSA document needs to focus on the issues facing
>>the next few years, and simply make reference to the problems of
>>automating the semantic alignment of operations and data that will
>>still be there when the short-term issues are solved.
>>
>>So, there is a problem, but lots of useful work can be done without
>>solving it, and there are worse problems to solve first. After all,
>>businesses have been coping with these semantic mismatches for
>>centuries while the mechanical aspects of business communication have
>>been improved. Sure, at some point the mechanical stuff will be
>>nailed down
>>and then the labor-intensive, error-prone approaches used by
>>application
>>writers to align semantics will be the worst problems that systems
>>integrators face, but there is a lot of work to do before we
>>are in that
>>situation.
>>
>>
>>
>>
>>
>>
>
>
>
>
>