ebBP 10/27/2005: Specification Element Changes (Spec and Schema)

[Monica J Martin <Monica.Martin@Sun.COM>]

In line with our agreement at our last meeting 18 October 2005, here is 
the proposed updated text on the Specification element with the addition 
of the DocumentDefRef attribute. I've included both the proposed 
technical specification text and the schema snippet for the 
Specification element. Please provide comments this week. The updates 
are in line with our agreement, meeting minutes from the last two 
meetings and via email. Thanks and comments sure welcome and 
appreciated. Many thanks to Stephen Green, Dale Moberg, and John Yunker 
for their inputs here (actually the entire team is to be thanked).

Technical specification:
Section 3.4.6 2
Change from: Specification elements

A Specification element provides the type, location, target namespace 
and identifier of the specified elements. If the logical Business 
Document uses different namespaces, each of which has a schema, any or 
all may be specified using a sequence of Specification elements. For 
example, the retail industry uses a logical Business Document and 
requires different parts be identifiable (i.e. multiple references to 
the content structure exist which may include multiple schemas and/or 
namespaces). The specificationVersion may be “2” while the actual 
(current) artifact document version is “2.0.1”.

It is relevant to note that the ebBP technical specification focuses on 
the logical Business Document not a wire format. The goal was to keep 
logical separation of functions between implementation and the processes 
described. Therefore, in maintaining that abstraction, focuses on 
providing a DocumentSpecificationType that points to more information 
about that specification. This capability also may assist in providing a 
hint to a system, while also allowing an application, middleware or a 
service, to bound what it may be capable of processing. An ebBP 
implementation MAY use DocumentSpecificationType element to point to 
implementation specific details that it is capable of processing.

For example, several user communities are or anticipate using a small 
business Universal Business Language (UBL) subset, the use of a hint 
could enable an iterative step to automate their processes and provide 
flexibility in the use of context or semantic conditions understood by 
those groups. In this scenario, the use of 'other' enumeration value for 
the DocumentSpecificationType allows the integration of a human decision 
into a process (alert). The message exchange at the transport level and 
as defined in the CPA, resolve down to physical Business Documents. In 
addition, by user community request, 'schematron' has been added as an 
enumeration value to assist in providing a pointer to validation 
capabilities.

Change to: Specification element
A Specification element provides the type, location, target namespace 
and identifiers of the specified elements. If the logical Business 
Document uses different namespaces, each of which has a schema, any or 
all may be specified using a sequence of Specification elements. For 
example, the retail industry uses a logical Business Document and 
requires different parts be identifiable (i.e. multiple references to 
the content structure exist which may include multiple schemas and/or 
namespaces). The specificationVersion may be “2” while the actual 
(current) artifact document version is “2.0.1”.

It is relevant to note that the ebBP technical specification focuses on 
the logical Business Document not a wire format. The goal was to keep 
logical separation of functions between implementation and the processes 
described. The logical business document is a semantic document. It 
describes the semantic content and purpose of a physical document and 
also may include the semantic business objective. For example, a 
physical Purchase Order Response document may be mapped to two or more 
logical documents in ebBP, "AcceptPOResponse" / "RejectPOResponse" or 
"ShipImmediatePOResponse" / "HoldForReleasePOResponse". The logical 
business document drives the business process. This allows the 
flexibility to describe and use semantic information from a business 
perspective while remaining agnostic to what happens at transport level 
in order to move through a series of states given the transfer of a 
business document.

Business documents also convey states. The ebBP process definition can 
provide a semantic view of how the semantic document type, its state and 
key elements can be used to drive the business process. This logical 
view maintains the value of the business process and its underlying 
business collaboration states. In addition to use of variables on 
condition expressions that are semantic element declarations (see 
Section 3.4.11.1.1) that drive the process, an external document 
reference is available in the Specification element, called 
DocumentDefRef. An example of its use could be, a local government may 
have variability in how procurements occurs. Using the DocumentDefRef 
(in addition to other Specification detail), that entity may need to 
point to third-party information to provide additional detail to control 
the use of that business document. This functionality is particularly 
relevant for user communities interested in using such as Universal 
Business Language (UBL) , UBL Small Business Subset (SBS) or high 
technology trading domains.

The logical business document also provides a DocumentSpecificationType 
that points to more information about that specification. This 
capability also may assist in providing a hint to a system, while also 
allowing an application, middleware or a service, to bound what it may 
be capable of processing. An ebBP implementation MAY use 
DocumentSpecificationType element to point to implementation specific 
details that it is capable of processing.

For example, several user communities are or anticipate using a small 
business UBL subset, the use of a hint could enable an iterative step to 
automate their processes and provide flexibility in the use of context 
or semantic conditions understood by those groups. In this scenario, the 
use of 'other' enumeration value for the DocumentSpecificationType 
allows the integration of a human decision into a process (alert). The 
message exchange at the transport level and as defined in the CPA, 
resolve down to physical Business Documents. In addition, by user 
community request, 'schematron' has been added as an enumeration value 
to assist in providing a pointer to validation capabilities.

Schema:
Change from:

    - <#> <xsd:element name="*Specification*">
    - <#> <xsd:annotation>
    <xsd:documentation>A specification element that can associate many
    references to a particular ebBP element. For example, multiple
    specifications associated with a logical Business Document. Note:
    This element was added in v2.0.</xsd:documentation>
    </xsd:annotation>
    - <#> <xsd:complexType>
    - <#> <xsd:attribute name="*type*"
    type="*DocumentSpecificationType*" use="*optional*" default="*schema*">
    - <#> <xsd:annotation>
    <xsd:documentation>This attribute defines the type of the
    Specification of the particular ebBP element. Note: This attribute
    was added in v2.0.</xsd:documentation>
    </xsd:annotation>
    </xsd:attribute>
    - <#> <xsd:attribute name="*location*" type="*xsd:anyURI*"
    use="*required*">
    - <#> <xsd:annotation>
    <xsd:documentation>The location of the Specification of the
    particular ebBP element. Note: This attribute was added in
    v2.0.</xsd:documentation>
    </xsd:annotation>
    </xsd:attribute>
    - <#> <xsd:attribute name="*targetNamespace*" type="*xsd:anyURI*"
    use="*optional*">
    - <#> <xsd:annotation>
    <xsd:documentation>The target namespace of the Specification of the
    particular ebBP element. Note: This attribute was added in
    v2.0.</xsd:documentation>
    </xsd:annotation>
    </xsd:attribute>
    <xsd:attributeGroup ref="*name*" />
    </xsd:complexType>
    </xsd:element>

Change to:

    - <#> <xsd:element name="*Specification*">
    - <#> <xsd:annotation>
    <xsd:documentation>A specification element that can associate many
    references to a particular ebBP element. For example, multiple
    specifications associated with a logical Business Document. Note:
    This element was added in v2.0.</xsd:documentation>
    </xsd:annotation>
    - <#> <xsd:complexType>
    - <#> <xsd:attribute name="*type*"
    type="*DocumentSpecificationType*" use="*optional*" default="*schema*">
    - <#> <xsd:annotation>
    <xsd:documentation>This attribute defines the type of the
    Specification of the particular ebBP element. Note: This attribute
    was added in v2.0.</xsd:documentation>
    </xsd:annotation>
    </xsd:attribute>
    - <#> <xsd:attribute name="*location*" type="*xsd:anyURI*"
    use="*required*">
    - <#> <xsd:annotation>
    <xsd:documentation>The location of the Specification of the
    particular ebBP element. Note: This attribute was added in
    v2.0.</xsd:documentation>
    </xsd:annotation>
    </xsd:attribute>
    - <#> <xsd:attribute name="*targetNamespace*" type="*xsd:anyURI*"
    use="*optional*">
    - <#> <xsd:annotation>
    <xsd:documentation>The target namespace of the Specification of the
    particular ebBP element. Note: This attribute was added in
    v2.0.</xsd:documentation>
    </xsd:annotation>
    </xsd:attribute>
    - <#> <xsd:attribute name="*DocumentDefRef*"
    type="*xsd:normalizedString*" use="*optional*">
    - <#> <xsd:annotation>
    <xsd:documentation>A name, URN or other reference that cites a
    specification or external reference that defines the document. This
    attribute was added in v2.0.1.</xsd:documentation>
    </xsd:annotation>
    </xsd:attribute>
    <xsd:attributeGroup ref="*name*" />
    </xsd:complexType>
    </xsd:element>