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

["David RR Webber \(XML\)" <david@drrw.info>]

I've always understood logical document to be tied to a specific business purpose or function.

 

Then we add context and role to the equation. And then partners can agree specifically what binding between the logical documents and what they actually want to use physically as transactions to perform those logical exchanges.

 

The 'good enough' approach here has to be the view - clearly in theory nothing on the web is guaranteed to ever remain where you said it was.  So any location details can change over time.

 

However - we're looking here for a design level reference, that can be taken and bound to a runtime environment by partners explicitly agreeing - using MoUs, CPA's and such to clarify the actual locations for those engagements.

 

Also entities - such as UBL, or other industry domains will publish their own reference BPSS models and instances.

 

Whether they use a registry to publish those, and whether they reference other peoples locations - eg the BPSS is in one registry and the document references are on another site - that is entirely at their descretion.

So summarizing this - the BPSS carries the logical document definition that serves as a guide to implementers, who then need to bind to the explicit instances they want - either with the BPSS itself, or using CPA in tandem.

 

In practice today the ebMS transport layer is dictating this through the CPA references to document definitions and the service/action pair (that references back to the BTA in the BPSS).   I can envision that people will add BPSS-aware handlers into their ebMS engine that can track state between two partners - and reference the BPSS instance to control that (eg not only checking service/action - but if that service/action is permitted at that point in the collaboration).  Implicit in that is linkage to the content of the transactions - and we've added the XPath mechanism to BPSS to be able to provide that. And because of the new variable tools we've added - you can set role and context and have those referencable by that content service - especially for context driven validation - and CAM definately gives you that capability.

 

That is a quick thumbnail sketch drilldown!  

 

I do believe that for V2 we have enough to empower that extended use case.  Beyond that gets into the realm of things we've tabled for V3 and also the new ebSOA work on patterns and deployment architectures. And then the BCM work is teaching how this links to business layers of the solution and how each component facilitates a layered approach that is vital to manage complexity and provide agility.

 

Hope that is helpful.

 

Thanks, DW

> -------- Original Message --------
> Subject: RE:
> [ebxml-bp] ebBP 10/10/2005: Specification and
> Logical
> BusDocuments
> From: "Stephen Green"
> <stephen_green@bristol-city.gov.uk>
> Date: Tue, October 11,
> 2005 11:11 am
> To: <ebxml-bp@lists.oasis-open.org>,
> <jean-jacques.dubray@sap.com>
> Cc:
> <tmcgrath@portcomm.com.au>,
> <Jon.Bosak@Sun.COM>
>
> 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]