Todd
> I understand you're recommending that BSPs on the internet look first
> at the immediate requirements, process, and modules and then look for
> existing matching structures. Do you mean, business XML schema vocabularies?
> or the whole universe of structures such as SOAP?
Ideally from existing vocabularies, whether or not they be expressed as schemas, DTDs,
EDIFACT directories, etc.
> I understand that you believe no standard vocabulary will
> ever exist, ergo, each BSP should build custom integrations with each
> of their integration partners.
Where did you get this idea from? I said that no such vocabulary will ever meet the
needs of all user communities. There will be a "standard vocabulary", when ebXML is
successfully completed.
> Since there will be repositories
> and registries like biztalk, or future ebxml servers, to assist us
> mapping our synonyms with our partners, or executing objects for
> adapters, it is not critical to pursue any common vocabulary and
> semantics at this time.
Agreed
> But I reject that conclusion based on 20+ years experience with
> hundreds of small and medium scale accounting and business systems.
>
> I promise you, there is a collection of elements which is universal
> and which will end up being expressed in a vocabulary to "get the
> job done". This is fairly widely recognized in SMEs and participants
> in standards bodies. For example, there is a "Standard Purchase Order"
> initiative within the OAG right now, and a metadata project.
> The broad success of the two BASDA EBIS documents, Purchase Order
> and Invoice, are another example http://basda.org/schema/index.htm.
My point was that there well be organizations for who the "standard purchase order"
can only be a starting point in the design process, rather than the tool they actually
use.
>
> There will be many optional fields but there will be a common core.
> Eventually I expect these "universal PO standards" will converge, and
> more documents will emerge for the surrounding choreography, and for
> other transaction types: payments, bids, offers, etc.
Whilst convergence will happen it will never be complete.
>
> I reject the advice that small BSPs should develop XML interfaces
> optimized only for their immediate integration project, and
> particularly, the idea that individual developers should define and
> discover the level of modularity for business exchanges on an ad-hoc
> basis. This will cause the classic N-squared problem and an excessive
> logic requirement in mapping these wonderfully diverse module interfaces.
I never made that point. What I said was that for the time being (today) you need to
start from what is available, but in the longer term be ready to move over to using
ebXML.
>
> The most practical approach today, by systems developers is to expand
> the scope of their interface project beyond the first 1 or 2 partners.
Agreed
> Developers need to realize that the large software and consulting
> company employees who are designing standards, are not primarily
> interested in practical A2A interoperability for SMEs. They are solving
> problems for the fortune 100, or trying to sell a lot of middleware
> servers, or whatever. Since SMEs aren't at the meetings, their
> interests are simply not reflected in the process.
At the practical level I work at (the core components group) the problem is the
reverse. Getting the big companies to join the SMEs actually doing the work in a
huddle in a back room is proving the difficulty. I can assure you SMEs are involved in
the process at core component level.
> ebXML will probably provide a standard, manageable transport framework
> which will be terrific for SME's based on the HTTP/MIME they're talking
> about. But ebXML does not seem disposed to defining payload elements
> like "AddressLine1". They're not a vocabulary provider. Anyway, I
> seem to detect that the vocabulary providers want ebXML to
> "stay out of their turf".
That is simply untrue. The ebXML core components group is working on this. Later this
month we will be publishing something on this. (There is a meeting to finalize the
published data this Thursday!)
Martin Bryan
Chair, CEN/ISSS Defining and Managing Semantics and Datatypes project group
==========================================
XML/EDI Group members-only discussion list
Homepage = http://www.xmledi.org
Brought to you by: Online Technologies Corporation
Home of BizServe - www.bizserve.com
TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]>
Leave the subject blank, and
In the body of the message, enter ONLY: unsubscribe
Questions/requests should be sent to: [EMAIL PROTECTED]
To join the XML/EDI Group complete the form located at:
http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
