RE: [ebxml-bp] ebBP 10/10/2005: Specification and LogicalBusDocuments

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Thanks, this seems to be yet another meaning
to the ones Tim and I supposed.

All the best

Steve

>>> "Dubray, Jean-Jacques" <jean-jacques.dubray@sap.com> 11/10/05 15:52:58 >>>
Stephen:

A "logical" document is a pyshical document combined with some rules

For instance, I can have a generic confirm document (like the OAG
confirm BOD)

I can create two logical documents from it

Accept PO: confirm document where \\@document="PO" &
\\@documentState="Accepted"
Reject PO  \\@document="PO" & \\@documentState="Rejected"

Jean-Jacques
-----Original Message-----
From: Stephen Green [mailto:stephen_green@bristol-city.gov.uk] 
Sent: Tuesday, Oct 11, 2005 7:31 AM
To: ebxml-bp@lists.oasis-open.org 
Cc: tmcgrath@portcomm.com.au; Jon.Bosak@Sun.COM 
Subject: Re: [ebxml-bp] ebBP 10/10/2005: Specification and Logical
BusDocuments

Monica

Tim McGrath raised an interesting question on the ubl list:
what exactly is meant by logical business document? Tim's
understanding was that it was a document's model. Mine
was that a logical document is one that may include other
documents but is regarded as just one document 'logically'.

I reckon this needs some exact agreement and definition
since it clearly has different possible interpretations which
could make a big difference to this matter.

All the best

Stephen Green

>>> Monica J Martin <Monica.Martin@Sun.COM> 11/10/05 00:04:15 >>>
As you can see (see post at end of this email), Stephen is soliciting 
comment from the UBL TC and their user communities on our discussions 
around the Specification element and logical business documents. Here is

a summary in preparation for tomorrow's call.

Summary
======
Given the abstraction in the collaborative process, a logical business 
document may be specified that actually encompasses or is realized by 
many document fragments (not the wire format). In ebBP, the goal was to 
keep logical separation of functions between implementation and the 
processes described. Therefore, in maintaining that abstraction, an 
element and simple type were developed

    * The Specification element provides the means to quantify that
      logical business document coupled with the
DocumentSpecificationType.
    * The DocumentSpecificationType is provided that points to more
      information about the 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.

We've discussed these variable conditions:

    * The need and, if so, how to generalize for other document types
      (other than schema) in addition to what is currently defined.
    * In business, the location of a document fragment may change (and
      often). It is uncertain what other external capabilities or
      services that communities may use (for example, a location pointer
      to a text document combined and used with other external automated
      capabilities).
    * If a URN is used, what need exists for another identifier
      (assuming that the location could change) and that automation
      capabilities may differ.
    * Recognition that in the future registries may be used although
      small businesses may lack the resources (at least initially) to
      use them.

Schema fragments
============
Current Specification element

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

Current DocumentSpecificationType

    - <#> <xsd:simpleType name="*DocumentSpecificationType*">
    - <#> <xsd:annotation>
      <xsd:documentation>The simpleType related to the enumerated list
    of specification types for the Specification element. Note: This
    simpleType was added in v2.0.</xsd:documentation>
      </xsd:annotation>
    - <#> <xsd:restriction base="*xsd:NMTOKEN*">
      <xsd:enumeration value="*schema*" />
      <xsd:enumeration value="*dtd*" />
      <xsd:enumeration value="*wsdl*" />
      <xsd:enumeration value="*relaxng*" />
      <xsd:enumeration value="*schematron*" />
      <xsd:enumeration value="*other*" />
      </xsd:restriction>
      </xsd:simpleType>

Solution options
===========
We've identified the three focus areas and options (related to any 
consideration of a change on the Specification element).

   1. Machine processing: Specification attributes are used by software,
      services or middleware. Therefore, another attribute may be
      beneficial.
   2. Human intervention: Attributes used actually allow raising
      information to an analyst or expert in the process. Existing
      attributes and an example may be sufficient.
   3. Both (variable): Could defer to option 1 but provide an example
      that supports 2.

We'll discuss how to proceed tomorrow if we can (and welcome comments 
from our user communities). Regards.

[start stephen green post to UBL]

>green: Greetings,
>I was asked on the last ebBP (ebXMl Business Process) TC 
>call to put a request to UBL members:
>
>Background
>
>We have been looking at how to use the latest public review
>draft of the ebBP version 2.0.1 to specify, in particular, for
>example, UBL logical documents in a business process. By
>logical documents is meant not so much the various imported
>XSD schemas necessary, say, among other schemas, etc in
>a document but the overall document such as a UBL Invoice.
>However I have commented that in order to specify what is
>meant by that logical document, in a real, typical situation, it
>would be necessary to specify more than just the document
>schema (e.g. ...UBL-1.0-Invoice.xsd) but also other artefacts
>defining the document such as any formal subset and possibly
>a set of codelists - most of which might not necessarily take
>the form of XSD schemas but could include Schematron
>schemas and other XML documents. These together would
>constitute the definition of the logical business document, 
>though usually the main artefact would be, in UBL's case, the
>document XSD schema. ebBP indeed provides several 
>occurances of an element //Specification for each logical
>document to cater for this. 
>
>The 'Specification' element in ebBP 2.0.1 so far has attributes for 
>'location' and 'type' of a schema or other document-defining 
>artefact. Also there is a 'targetNamespace' attribute which is 
>optional and obviously applies primarily to those types of artefact 
>which include the specifying of a targetNamespace. I have 
>commented that it would make sense to cater for artefacts which
>do not have their own, specified targetNamespace by adding 
>a further attribute to allow the specification of an appropraite
>identifier for these in addition to the 'location' and schema 'type'.
>
>Request
>My example backing up my comment would likely be the UBL
>Small Business Subset which has its own identifying urn but does
>not provide any namespace other than the corresponding UBL
>document targetNamespace. 
>
>Would anyone provide another example, perhaps for codelist
>documents or the like, either for UBL or any EDI-related situation?
>
>Such an example might include the attributes 'location' and
>a new attribute, say called 'ID' to point a 'Specification' element
>(in an ebBP definition instance) to one of several artefacts which
>define a logical business document. Perhaps a set of Specification
>elements could together be provided to define a single logical
>document. The more realistic the better I guess. Maybe the 
>'location' attribute would in some cases be sufficient or just that
>and the optional 'targetNamespace' attribute, if appropriate.
>
>Any help would be appreciated. Thanks.
>
>All the best
>Stephen Green (as ebBP TC/UBL TC liaison)
>
[end stephen green post to UBL]