OASIS Charter Submission Discuss

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

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
                                                
                                                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 

And let's not forget the OASIS CMIS Standard.



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Jeremy Roberts [mailto:jeremy@lonmark.org] 
Sent: Wednesday, October 27, 2010 12:38
To: oasis-charter-discuss@lists.oasis-open.org
Subject: RE: [oasis-charter-discuss] BusDox: Charter issue

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 


---------------------------------------------------------------------
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 

Folks,

I don't see any relationship between
the BusDox proposal and OASIS CMIS.


Yours,  Mike.


Strategist - Emerging Technologies, SCA & SDO.

Co Chair OASIS SCA Assembly TC.

IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.

Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

Email:  mike_edwards@uk.ibm.com





From:
"Dennis E. Hamilton" <dennis.hamilton@acm.org>

To:
"'Jeremy Roberts'" <jeremy@lonmark.org>,
<oasis-charter-discuss@lists.oasis-open.org>

Date:
28/10/2010 03:53

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





And let's not forget the OASIS CMIS Standard.




                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----

From: Jeremy Roberts [mailto:jeremy@lonmark.org]

Sent: Wednesday, October 27, 2010 12:38

To: oasis-charter-discuss@lists.oasis-open.org

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


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



---------------------------------------------------------------------

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



---------------------------------------------------------------------

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















Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU

I assume you mean there is no relationship between the two, as
opposed to not seeing one but wanting one?



Martin.









From: Mike Edwards
[mailto:mike_edwards@uk.ibm.com]

Sent: 28 October 2010 09:53

To: oasis-charter-discuss@lists.oasis-open.org

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









Folks,


I don't see any
relationship between the BusDox proposal and OASIS CMIS.



Yours,  Mike.


Strategist - Emerging Technologies, SCA & SDO.

Co Chair OASIS SCA Assembly TC.

IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.

Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

Email:  mike_edwards@uk.ibm.com





 

  

  
From: 
  
  

  
"Dennis
  E. Hamilton" <dennis.hamilton@acm.org> 
  
 
 

  

  
To: 
  
  

  
"'Jeremy
  Roberts'" <jeremy@lonmark.org>,
  <oasis-charter-discuss@lists.oasis-open.org> 
  
 
 

  

  
Date: 
  
  

  
28/10/2010
  03:53 
  
 
 

  

  
Subject: 
  
  

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














And let's not forget the OASIS CMIS
Standard.




                                                

					
                                                    

        
                                                
				

                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----

From: Jeremy Roberts [mailto:jeremy@lonmark.org] 

Sent: Wednesday, October 27, 2010 12:38

To: oasis-charter-discuss@lists.oasis-open.org

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


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 



---------------------------------------------------------------------

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 



---------------------------------------------------------------------

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 


















Unless
stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Martin,

I mean that I can't see that there is
any relationship between the two.  

OASIS CMIS and BusDox deal with different
things.


Yours,  Mike.


Strategist - Emerging Technologies, SCA & SDO.

Co Chair OASIS SCA Assembly TC.

IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.

Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

Email:  mike_edwards@uk.ibm.com





From:
Martin Chapman <MARTIN.CHAPMAN@oracle.com>

To:
Mike Edwards/UK/IBM@IBMGB, oasis-charter-discuss@lists.oasis-open.org

Date:
28/10/2010 15:03

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





I assume you mean there is
no relationship between the two, as opposed to not seeing one but wanting
one?
 
Martin.
 
From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]


Sent: 28 October 2010 09:53

To: oasis-charter-discuss@lists.oasis-open.org

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


Folks,



I don't see any relationship between the BusDox proposal and OASIS CMIS.



Yours,  Mike.


Strategist - Emerging Technologies, SCA & SDO.

Co Chair OASIS SCA Assembly TC.

IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.

Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  

Email:  mike_edwards@uk.ibm.com





From:

"Dennis E. Hamilton"
<dennis.hamilton@acm.org>


To:

"'Jeremy Roberts'" <jeremy@lonmark.org>,
<oasis-charter-discuss@lists.oasis-open.org>


Date:

28/10/2010 03:53


Subject:

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

 








And let's not forget the OASIS CMIS Standard.




                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----

From: Jeremy Roberts [mailto:jeremy@lonmark.org]

Sent: Wednesday, October 27, 2010 12:38

To: oasis-charter-discuss@lists.oasis-open.org

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


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



---------------------------------------------------------------------

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



---------------------------------------------------------------------

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











 
Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU 


















Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598.

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU