RE: [oasis-charter-discuss] BusDox: Charter issue

["Jeremy Roberts" <jeremy@lonmark.org>]

I too have questions similar to those of Ed (so for brevity, I won't go
into them).  If someone closer to the project could give a comparison of
this proposal to WebDAV, then many of my questions may be moot. 

Thanks, 
- Jeremy 


Jeremy J. ROBERTS 
Technical Director 
LonMark International 


-----Original Message-----
From: Ed Barkmeyer [mailto:edbark@nist.gov] 
Sent: Wednesday, October 27, 2010 11:39 AM
To: oasis-charter-discuss@lists.oasis-open.org; David Connelly
Subject: [oasis-charter-discuss] BusDox: Charter issue

The intent of the BusDox project is described in the Charter as three 
different ideas:

1. "The BusDox TC does not replace existing messaging service standards.

It provides a simplified interface independent of the various standards 
used for the exchange of documents."

Interface between what and what?  "independent of the standards used for

exchange" appears to be completely inconsistent with the description of 
the TC output as a set of Profiles for the standards used for exchange.

What was really intended here?

2.  "Establish profiles for a lightweight and federated document 
transport infrastructure supporting secure and reliable exchange of 
electronic business documents."  followed by many other bullets that 
begin "Profile ... (some other network services standard)"

This seems to be a good idea, consistent with several efforts of CEN and

the EU -- to standardize a set of protocols and options for business 
document transmission, so that there is a well-defined layer cake of 
protocols that create interoperability at every layer below the document

definition itself.  But if this is the intent of the TC, then it defines

a total end-to-end interface _/in terms of /_existing and emerging 
standards, not _/independent of/_ them, as the sentence cited as (1) 
above says.

3.  "List of deliverables
The BusDox TC will produce an integrated set of Committee Specifications

including a set of XML Schemas and an XML-based request/response 
protocol for exchange of documents."

I do not understand how a Profile or a set of Profiles is an XML Schema,

or is usefully rendered as one.  Presumably the business documents 
themselves are defined by standard XML Schemas chosen by the businesses,

e.g., ebXML or OAGI or PLCS or whatever.  And every layer of the Profile

below the document level is simply a specific configuration of the 
referenced standards for that part of the addressing, packaging and 
transmission controls.  So what kind of XML schema would this TC 
provide?  And for whose consumption?

The intent of the XML Schema appears to be an additional activity not 
mentioned in the Scope (as interpreted from "The committee 
Specifications will cover" list) -- the definition of an "XML-based 
request/response protocol for exchange of documents".  And it is not 
clear which bullet of the objectives list would lead to this activity.  
Whatever this "development of a request/response protocol" is, it should

be made one of the bullets of one of the lists.

This undescribed activity seems to be a direct replication of the ebMS 
effort, to say nothing of the OAGIS and CEFACT simple webservices 
commonly in use, bearing in mind that those standards define standard 
document forms, and include acknowledgement messages (for asynchronous 
one-way messages) and request-with-response rules for the use of 
others.  So it appears that the objective of this TC is not only to 
profile the lower layers of the layer cake, but also to create yet 
another standard for the actual business message envelope at the top
level.

Simply stated, creating a standard profile for the layers of the layer 
cake is a very worthwhile task.  Adding yet another "simple" messaging 
standard for conveying an arbitrary text or XML payload is not clearly a

worthwhile endeavour.  Choosing an existing standard for that purpose, 
as part of the overall Profile, would be consistent with the overall 
intent of creating a standard interoperable suite of layers for 
conveying arbitrary business documents.

I believe the Charter needs to be clarified in these regards, so that 
the intent of this project is clear to the WS-I folk,  the ebMS folk, 
and the CEFACT folk. 

Further, it is not clear that the identified participants include any 
individuals who have been involved in any of the major standards that 
are to be profiled, or any of the "similar or applicable work".  Yet no 
formal liaisons are identified.  Some significant effort must be made to

create and operate the liaisons between this TC and the organizations 
responsible for the standards the TC expects to Profile, and the 
implementors of those standards, lest this whole project result only in 
academic shelfware.

-Ed Barkmeyer

-- 
Edward J. Barkmeyer                        Email: edbark@nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php