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

["Mark CRAWFORD"<mcrawfor@mail.lmi.org>]

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"