OASIS Open

The concept Agreement Formation Descriptor Document (AFDD) is a proposal for a document that describes how business partners establish business agreement documents. It recognizes: - multiple types of agreement documents, such as XML schemas, WSDLs and ebXML Collaboration Protocol Agreements. - multiple ways of establishing those documents, including transformation of templates with particular variable parts (using values provided by business partners), intersection of ebXML Collaboration Protocol Profile documents, or combinations. - the need to have multiple agreement documents, such as a CPA or WSDL and an XML Schema referenced in that CPA or WSDL. The attached ZIP file provides - an XML schema for AFDD documents - a compiler that generates XSLT stylesheets to perform document transformations (XSLT and Python driver) - a script to evaluate the generated XSLT scripts (Python driver) AFDD documents can specify CPP intersection, but the compiler does not support this formation method. Sample documents are included: - bias.afdd: simple CPA template, where one partner acts as server (setting start, end and CPA id) and the other provides communication details. - cppintersection.afdd: CPA formed on the basis of two supplied CPPs - multidoc.afdd: two partners agree on a specialized business document schema (a UBL invoice where the optional "OrderReference" element has been made required) and a CPA that references this schema. - multiparty.afdd: three business partners form two CPAs based on three CPPs. - secured.afdd: real-life, complex CPA using XML digital signatures, XML encryption and TLS authentication, reliable messaging. Two partner need to supply four certificates each, their party identification parameters. Optionally, reliable messaging parameters can be adjusted. - ubl.afdd: the XSD specialization also used in multidoc.afdd - wsdl.afdd: an organization requires a business partner to implement a particular web service, where only the SOAP address is variable.

The concept Agreement Formation Descriptor Document (AFDD) is a proposal for a document that describes how business partners establish business agreement documents. It recognizes: - multiple types of agreement documents, such as XML schemas, WSDLs and ebXML Collaboration Protocol Agreements. - multiple ways of establishing those documents, including transformation of templates with particular variable parts (using values provided by business partners), intersection of ebXML Collaboration Protocol Profile documents, or combinations. - the need to have multiple agreement documents, such as a CPA or WSDL and an XML Schema referenced in that CPA or WSDL. The attached ZIP file provides - an XML schema for AFDD documents - a compiler that generates XSLT stylesheets to perform document transformations (XSLT and Python driver) - a script to evaluate the generated XSLT scripts (Python driver) AFDD documents can specify CPP intersection, but the compiler does not support this formation method. Sample documents are included: - bias.afdd: simple CPA template, where one partner acts as server (setting start, end and CPA id) and the other provides communication details. - cppintersection.afdd: CPA formed on the basis of two supplied CPPs - multidoc.afdd: two partners agree on a specialized business document schema (a UBL invoice where the optional "OrderReference" element has been made required) and a CPA that references this schema. - multiparty.afdd: three business partners form two CPAs based on three CPPs. - secured.afdd: real-life, complex CPA using XML digital signatures, XML encryption and TLS authentication, reliable messaging. Two partner need to supply four certificates each, their party identification parameters. Optionally, reliable messaging parameters can be adjusted. - ubl.afdd: the XSD specialization also used in multidoc.afdd - wsdl.afdd: an organization requires a business partner to implement a particular web service, where only the SOAP address is variable.

Draft notes not approved by TC members.

Comments welcome and will be factored in if received by Wed June 6, 2007.

Working draft of V 3 schema, incomplete and not yet approved by TC. Editor's draft only.