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:Expanded Outline for ebXML Requirements Document


Mike,

    I have reviewed the outline and have no major objections - other than I
don't agree with dropping organizational requirements.  I think those are key to
articulating what we expect of ebXML. We need to come to consensus on what the
long-term strategy for ebXML as an organization should be.  We should articulate
requisite organizational requirements to support achieving that long-term
strategy.  We should use those organizational requirements to define what we
believe are the functional requirements and processes of the individual work
groups.  I realize the ebXML steering (or is it advisory?) committee might be
the more appropriate body to reach consensus on the organizational issues,
however I believe we have the charter to at least articulate what we see as the
requirements and to provide our recommended approach. I also think our group,
once the initial functional requirements are articulated to the larger ebXML
body, should continue in existence to further work the organizational
requirements in behalf of, or in conjunction with, the ebXML steering committee.

The following is the beginnings of what I see as the list of major
organizational requirements issues we need to address - 

What do we, as business standards consensus building experts (as opposed to
parochial X12/CEFACT/OASIS members) believe should be the solution for the
ever-expanding universe of stovepiped XML DTDs and schemas? How do we go about
making that solution a reality?
What are the short and long term strategies of ebXML as an entity?
Are we creating XML standards development and management solutions to be
implemented by OASIS, CEFACT, or ebXML?
If we are developing solutions to be implemented by ebXML, how is ebXML
management to be accomplished on both the short and long terms? Funded (same
points of reference)?
Should an ebXML standards development process follow those of W3C? X12? CEFACT?
ISO? Other?
What should be the long-term relationship between ebXML and CEFACT? W3C? ANSI?
ISO?
What should be the long-term relationship between ebXML and OASIS? BizTalk?
CommerceOne? RosettaNet? Other XML standards bodies?
What do we define as success?  How do we achieve it?

With respect to functional requirements, I believe we need to include the
following where appropriate within your outline -

Should ebXML business standards follow the structure of existing X12 transaction
sets?  EDIFACT Message models? BizTalk Schema?  RosettaNet PIPs? Other existing
standards?
Should ebXML tags replicate, incorporate, identify, reference, or otherwise
align with EDIFACT/X12/HL7 data element/code semantic names and syntactic
requirements?
Should ebXML tags replicate, incorporate, identify, reference, or otherwise
align with those of BizTalk, RosettaNet, XML.ORG, CommerceOne, or other XML
business standard efforts?
How can ebXML products best coalesce the structure and content components of the
above stated standards into a single useable XML business standard?
What are the right design rules for XML DTD's?  Schema's?
What is the impact of building ebXML business standards that use the various W3C
technical specifications as the underlying syntax when ebXML has no control over
those specifications?
What is the impact of the current immaturity of various technical specifications
on ebXML work in the short term?  Long term?
Should ebXML create its own XML business standards repository or use XML.ORG?
BizTalk? Other?
If ebXML creates an XML business standards repository, who will maintain it? 
Control access?  Create interfaces with other existing and planned repositories?

Moving to a more personal perspective, my client base consists of various
agencies within federal and state governments.  Within that client base,
mainframe legacy systems will continue for many years, EDI use will continue for
many years, XML implementation will be as varied as the business process and
organizational structures involved - both within and across business unit and
agency boundaries.  The agencies, either individually or collectively, can not
afford to participate in every collaborative standards effort underway.  As a
result - unless ebXML or some other universally accepted XML business standards
development and maintenance body is successfully established - their business
requirements will not be addressed across the full range of developing XML
business standards.  This will lead to sub-optimizing XML use within the
government through deployments that consist of a combination of assorted XML
business standards and internally developed federal XML schema's and tags.   
    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