OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-requirements message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Re[2]: Con Call Details for 1/13 - Updated Issues List


Hi folks:

Just want to share some of my thoughts and findings.

On the "Interoperability" issue, I am in agreement with Mark C. There
are a stream of XML/EDI solutions (or attempts) out there, and I don't
see a value add of us reinventing another one for the short term.
However, I do think that interoperability is an important criteria.
Large companies who have invested $$$ to their EDI investment will not
just discard EDI and join the XML band wagon.  So, even though my
preference is to develop an ebXML silver bullet, there is a reality
factor that we have to consider here.

My suggestion is to look into some of the "interoperability" solutions
or work efforts out there. Recently, I've been introduced to
CommerceNet's eCo Framework. Its actually a working group that has been
formed by CommerceNet to develop a flexible, extensible, and
interoperable e-commerce transaction framework. Since I'm still new to
this, I am in no position to elaborate the specifics yet. But based on
the web site, eco Framework is developing a base set of common terms
and mappings of existing e-commerce specifications i.e. EDI, ICE, OBI,
CDF and many more. (http://eco.commerce.net/)

If this can truly be a viable solution to our interoperability issue,
my preference is to develop a international standard across XML
applications and business standards.

T

Turochas Fuad "T"
eBiz Program Manager
Sun Microsystems, Inc.
turochas.fuad@sun.com








>X-Unix-From: mcrawfor@mail.lmi.org  Wed Jan 12 07:06:06 2000
>X-Authentication-Warning: lists.unicomp.net: majordomo set sender to 
owner-ebxml-requirements@lists.oasis-open.org using -f
>Date: Wed, 12 Jan 2000 09:58:23 -0500
>From: "Mark CRAWFORD"<mcrawfor@mail.lmi.org>
>To: <ebXML-Requirements@lists.oasis-open.org>
>Subject: Re[2]: Con Call Details for 1/13 - Updated Issues List 
>MIME-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Description: "cc:Mail Note Part"
>
>Greetings,
>
>Some thoughts interspersed with Mike's issues list follows -
>
>
>>1.  Conflict - Maximize interoperability with existing EDI implementations, or
>maximize
>>interoperability between ebXML applications.  
>
>>Proposed Consensus:  All other requirements aside, maximum interoperability
>between >ebXML applications has higher priority than maximizing 
interoperability
>with existing EDI >implementations.  However, having an initial solution within
>six months is also a high priority.  >If the former can't be achieved within 
six
>months and the latter can, then the latter has higher >priority.
>
>Sorry, I can't agree with this at all.  In my opinion, any six-month solution
>will not have value and will not be adopted by anyone.  There are already
>XML/EDI solutions out there, and there is not need to invent another one. 
>Better we look towards a long term solution that will achieve international
>interoperability across XML applications and business standards.  If EDI
>interoperability is achieved as a result, so much the better.  However, EDI
>interoperability is not, and should not be our driver in either the short or
>long term.  I very strongly believe if we focus on EDI interoperability, we 
have
>immediately limited our audience of potential users of an ebXML solution to
>those that currently do EDI.  Although that user base is quite large from a
>corporate $$ size perspective, it clearly is minuscule with respect to the
>number of existing or future B2B and B2C web trading partners.
>
>I think we can build the XML silver bullet.  Yes it will take a long time.  Too
>long is a matter of conjecture.  Certainly too long for anyone to wait on 
before
>doing XML.  Not too long for someone who wants to do XML quick and dirty, and
>then transition to a universal standard downstream.  One of the problems I see
>is that us standards folks are almost as rigid in our thinking that we have to
>have a single standard before going forward as the techie's are rigid in their
>thinking that new technology is "the" answer to all problems and standards are
>not necessary.
>
>
>>internationalization by supporting multi-lingual ebXML components?  If the
>latter, which >languages?
>
>>Consensus - Multi-lingual support has higher priority.
>
>I don't see this as an issue of priority at all.  I believe that multi-lingual
>support is a core requirement of any ebXML solution.  Remember the XML
>specification provides a linguistically neutral syntax for developing semantic
>understanding. Having said that, individual native language syntax requirements
>that may need to be addressed to ensure semantic understanding in a
>multi-lingual exchange must be accommodated. With respect to the question of
>which languages, I envision an iterative process wherein the ebXML solution
>includes a process for including new linguistic requirements as they become
>identified.
>
>>3.  Scope - Should the ebXML guidelines apply to business to consumer, or only
>business to >business?
>
>>Consensus - B2B should be the primary focus and B2C secondary.  Any
>requirements >specific to B2C are beyond our scope.  Automated B2C may be 
within
>our scope, but >presentation (in the sense of display to an end user) is not.
>
>This statement seems disjointed.  I agree that we may not want to get into
>Stylesheets.  However, to say that B2B focus is primary is to discount the vast
>majority of XML implementation underway today.  I disagree that requirements
>specific to B2C are beyond our scope.  Only the Stylesheet is beyond our scope. 
>All other aspects (unless a business is only involved in B2C with customers and
>has no B2B or B2C relationships with suppliers) are co-joined if we are to
>develop an interoperable solution that crosses business process and industry
>stovepipes.  
>
>>4.  Scope - Should the ebXML guidelines provide universally applicable cross
>industry >document definitions?
>
>>Consensus:  The guidelines should not provide these cross industry document
>definitions.
>
>Huh?  If you are saying we do not produce boilerplate Schema's/DTD's, then I
>disagree.  Although not a modeling person, my sense is any solution we develop
>must include the most basic of business models incorporated in schema's. The
>whole concept of hierarchical schema's and XSL transformations can be used as
>the basis for achieving our interoperability goal.  These definitions, or
>schema's, should be an outgrowth of business modeling work already underway by
>such folks as the OMG, RosettaNet, et. al. and should be used to develop an
>initial baseline of object models.
>
>
>    Mark
>Mark Crawford
>Research Fellow
>______
>LMI Logistics Management Institute
>2000 Corporate Ridge, McLean, VA 22102-7805
>(703) 917-7177   Fax (703) 917-7518
>mcrawfor@lmi.org
>http://www.lmi.org
>"Opportunity is what you make of it"
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC