Re: Kacker ebXML Requirements

[Mike Rawlins <rawlins@metronet.com>]

Here are my comments on Ravi's contribution.


>   ------------------------------------------------------------------------
>                                         XML Requirements - Ravi Kacker          Jan 4,2000
>
> Functional Requirements:
> - A global open /interoperable standard for specifying a document markup language based on plain-text tags.

The standard is a deliverable, not a requirement.

>
>
> - ebXML standards should support syntax independent message design guidelines which will harmonize EDI and future XML architectures.

I'm not sure that I understand this requirement.  Is this similar to saying that you want to be able to generate ebXML DTD's (or schemas) from syntax independent business models?   Are you also expressing a concern about interoperabiltity between current EDI and ebXML?

>
>
> - ebXML  standards DTD's limitations for controlled customization and extensibility should be avoided.

Please clarify.  Do you wish to restrict users from extending standardized DTDs or schemas?

>
>
> - ebXML global standards should be common to support both vertical and horizontal segments of industry and business participants and should not impose any financial or software requirements constraints on the respective partners to buy, instal or programmatically support any software products in the conduct of business information exchange.

I read two separate concerns - one a statement of scope: the ebXML standards should include both cross-industry (horizontal) as well as within industry (vertical) applications.  The other deals more with users imposing requirements or constraints on other users.  I think that is well beyond the scope of the ebXML work group.

>
>
> - ebXML standards should facilitate paper-less, electronic web /internet exchange of business information at the reasonable cost of internet service.

This seems to me to fit within my requirement of minimizing cost.

>
>
> - There should be ONE and ONLY ONE ebXML standard for software developers, business partners to adopt and should be free of constraints such as Version Numbers to upgrade to or migrate to keep uptodate. Each Version revision should continue to support past revisions.

A deliverable - a single ebXML standard.   I'm not sure of the point you're trying to make with the other part of your comment.  Are you expressing a requirement for backward compatibility between versions of ebXML?  Does that adequately express your concern?


>
>
> - Using ebXML defined standards, any parsing software tool can extract content  information exchanged between partners for processing by the receiver's  system  while displaying other content in different ways for viewers. The exchanged information in XML can also be viewed or displayed through available WEB browsers in the marketplace.

I think this deals with the functional requirements I derived from the Terms of Reference.

>
>
> - This XML exchange of information should help facilitate:
> - Business to Business commerce
> Direct data  interface to an XML compliant software without any translation or application integration software effort

I think this is captured in the functional requirements I offered.

>
> - Business to Consumer commerce
> Deliver business information exchanged to be viewed with a browser or extracted for data interface within consumer parner system

This is a scope issue.  I believe that OASIS and CEFACT had business to business in mind.  I am concerned that we may greatly increase scope if we include business to consumer.  I will put this on Friday's agenda as an issue.

>
> - Consumer to Business commerce
> Deliver response in XML to business information exchanged to the Business partner for direct data interface to their XML compliant application.

Same comment.

>
> - ebXML  standards if defined correctly  should be SIMPLE, EASY and UBIQUITOUS

No disrespect intended, but that's like my saying "Cheaper, faster, better".   These requirements are of little use without details.  Will you please be more specific?

>
> - ebXML standards have to be defined and adopted  by mid-year 2000. Any delay or debate or search of a PERFECT process for its definition beyond mid-year 2000 will only help boost  fragmented XML efforts in variety of industry sectors and a true opportunity for a global standards will be LOST forever.

A requirement to have the initial deliverable completed by mid-year 2000.

>
> - The process for ebXML standards definition and approval should follow a FAST TRACK guideline without bunch of Committees, Task Group approvals issues that have invariably stalled this effort.

I fully understand and share Ravi's frustration with the traditional EDI standards process.  However, we must have a broad based consensus if the work is to be of any long term usefulness.  Will you please be more specific regarding the what a fast track needs to do (not what it needs to be or how it does it) and perhaps some of the approvals
issues you would like to see addressed?


--
Michael C. Rawlins, Rawlins EDI Consulting
http://www.metronet.com/~rawlins/