ebxml-bp message

Subject: RE: [ebxml-bp] ebBP 11/8/2005: UBL Example and Changes Indicative of UBL v1.0 Standard

From: "David RR Webber \(XML\)" <david@drrw.info>
To: Monica J Martin <Monica.Martin@Sun.COM>
Date: Tue, 08 Nov 2005 10:06:44 -0700

Monica,

Are Deans flow diagrams available somewhere? (preferably in JPG)

I have only seen the XML for the BPSS itself.

I did work with that BPSS XML - essentially what it is describing is a model for a marketplace using UBL.

Some details get hazy - it is just a model - when trying to build an actual implementation from it.

I did get partially into the development of a full VisualScript model for the XML. However this is a non-trivial task involving at least a weeks work. Now that 2.01 BPSS is pretty much stable I plan to return to this task over the holiday break and making this scriptable.

The other thing is that actually the marketplace model is really comprised of five or six sub-models for the potential participants each, and then the overall collaboration across the marketplace.

Once you start to build that level of completeness - you do find that Deans original has gaps - nontheless - its a create start point for people - and just serves to illustrate the need for strong visual tools to allow business analysts to develop a full and robust implementation model(s).

For typical binary collaborations its OK to handcraft the XML - but a full up marketplace will tax even the best PhD brains and <anglebracket> afficiados!

-------- Original Message --------
Subject: [ebxml-bp] ebBP 11/8/2005: UBL Example and Changes Indicative
of UBL v1.0 Standard
From: Monica J Martin <Monica.Martin@Sun.COM>
Date: Tue, November 08, 2005 11:51 am
To: ebXML BP <ebxml-bp@lists.oasis-open.org>
Cc: "J. Dean E. P. Hemopo" <jdean@ebxml.co.nz>

Stephen Green and Dale Moberg have been reviewing Dean's
excellent/detailed UBL example to consider changes relevant to:

1. UBL v1.0 Standard now released: Stephen has some suggestions
(shown below).
2. External roles: Add usage of external roles and ensure the name,
nameID are correct (and lexically ordered - even though this is
not required by schema)
3. v2.0.1 Public Review changes such as Specification element:
Changed after v2.0.1 Committee Draft
4. Depth in line with flow diagrams Dean originally created: Flow
diagrams are more detailed than the actual ebBP process
definition. This is fine; we need to ensure this difference is
clearly stated.

What they have identified are some optimizations / changes to handle
1.-4. above and provide descriptive text identifying the examples focus
and intent. As with the other Negotiation and Small Business Subset
examples, we intend to place these in a separate appendices package.
Most of this is due to the size limitations of the technical
specification document (and problems generating .pdf). We may also have
other examples if Italian knitwear completes their detailed example in
time, or will post them later with references.

Here are Dale and Stephen's comments. Dean did a great deal of work and
we want to fully leverage that as well as evolve it further given our
liaison with UBL now.

Dale Moberg, 7 November 2005

Hi Monica,
As I explained on the call, I did consult the gif diagrams illustrating
the drop ship scenario in figuring out what to do with ExternalRoles.

I think I have a plausible resolution to that, but as I reviewed the
diagram and what was explicitly present in the described
BusinessCollaborations, I noticed some problems.

Minor problems include some gratuitous model elements. For example, a
Transition element is inluded that repeats the flow from the Start state
to the first BTA.

More troublesome, however, a very large amount of "glue" is missing in
the ebBP example that is in the model. For example, the model has a
decision element for rejecting an order, but there is no transition to
the order cancel logic, but just terminates with Success or Failure
states.

Upon looking at it, it seems a very partial rendition into BPSS of the
gif activity diagram. I am wondering how (or whether) we should retain
this illustration. It may give the impression of being a complete worked
out BPSS description of a UBL based collaboration, but is really just
fragments that of that process.
Dale

Stephen Green, 8 November 2005
Just looking at the UBL drop-ship example

I notice the following UBL-specific areas which would need to be improved if it were to be regarded
as accurate regarding UBL 1.0 (though as an example only I think it is great)

1. 
<Variable nameID="V800" name="PO Accepted" businessTransactionActivityRef="BTA1000" businessDocumentRef="O1000">
<ConditionExpression expressionLanguage="XPath1" expression="//AcknowledgementResponseCode='approved'[@codeListID='ACME3' @codeListAgencyID='ACME']"/>
</Variable>
<Variable nameID="V900" name="PO Rejected" businessTransactionActivityRef="BTA1000" businessDocumentRef="O1000">
<ConditionExpression expressionLanguage="XPath1" expression="//AcknowledgementResponseCode='reject'[@codeListID='ACME3' @codeListAgencyID='ACME']"/>
</Variable>

The document here seems to be an Order but the //AcknowledgementResponseCode is not meant
to be used to indicate acceptance or acknowledgement.

a. The Order/AcknowledgementResponseCode has one of two values 'OrderResponse' and 'OrderResponseSimple'
I'm not sure how Dean has used it but it should be used to specify at run-time the type of document the
Buyer wishes the Seller to use to respond to the Order. I would have to spend more time looking at how Dean's
example works to find out whether this is a necessary part of his process and whether this element should be used.

b. What I think it may be that this process example needs to do is to define something which indicates whether
an order has been accepted or rejected. There are two ways to do this with UBL and which one is used will
either depend on the process definition (I've not had time to look at this example in this amount of detail yet to
see whether it specifies this) or on the value given by the Buyer in 1a above (if the process definition allows). In
the latter case: (i) if the response document is an OrderResponseSimple then OrderResponseSimple/AcceptedIndicator,
an xml 'boolean' datatype (how the content of this actually looks in messages seems to be implemenation specific
but the definition in UBL specifies that 'true' and 'false' are the expected values), if 'true' (XPath '=true()' ??) denotes
accepted and if 'false' (XPath '=false()' ??) denotes rejected order (ii) if the response document is an OrderResponse
then the response document, the OrderResponse can be used to indicate detail about acceptance/rejection and also
substitution in various categories - much greater granularity of response perhaps than the drop-ship example caters
for but perhaps lacking in a clear way to just relate either acceptance or rejection (though maybe DocumentStatusCode
or the like could have a part to play in that - perhaps in a trading-agreement-specific way).

So you see it is quite a bit more complicated in reality than maybe Dean's example initially provides for - but the example gives a good start perhaps.

If the ConditionExpressions were changed to be more accurate in the example's Variable elements then it would probably be necessary to change the values for the businessDocumentRef in those acses too (since the documents might be inappropriate or incorrect for the more accurate examples).

2. I think the schema locations could be changed to the ones, with targetNamespace attributes added (and perhaps alternates
with SBS externalDocumentDefRefs too)

3. Dean has dummy codelist values such as ACME3 and ACME in
<ConditionExpression expressionLanguage="XPath1" expression="//AcknowledgementResponseCode='approved'[@codeListID='ACME3' @codeListAgencyID='ACME']"/>

and these could be changed to the UBL values

4. <Decision name="DEC100" nameID="DEC100">
<FromLink fromBusinessStateRef="BTA100"/>
<ToLink toBusinessStateRef="BTA100Success">
<ConditionExpression expressionLanguage="XPath1" expression="//AcknowledgementResponseCode='approved'[@codeListID='ACME3' @codeListAgencyID='ACME']"/>
</ToLink>
<ToLink toBusinessStateRef="BTA100Failure">
<ConditionExpression expressionLanguage="XPath1" expression="//AcknowledgementResponseCode='reject'[@codeListID='ACME3' @codeListAgencyID='ACME']"/>
</ToLink>
</Decision>

the same applies here as in 1. above

5. <Decision name="DEC150" nameID="DEC150">
<FromLink fromBusinessStateRef="BTA150"/>
<ToLink toBusinessStateRef="BTA150Success">
<ConditionExpression expressionLanguage="XPath1" expression="//DocumentStatusCode='true'[@codeListID='ACME1' @codeListAgencyID='ACME' ]"/>
</ToLink>
<ToLink toBusinessStateRef="BTA150Failure">
<ConditionExpression expressionLanguage="XPath1" expression="///DocumentStatusCode='false'[@codeListID='ACME1' @codeListAgencyID='ACME' ]"/>
</ToLink>
</Decision>

DocumentStatusCode exists in several documents in UBL 1.0 but the schemas provide the enumerations, of which 'false' is not an allowed value More work would be needed to analyse what needs to be substituted or corrected here too.

All this indicates a bit how much work might be needed if the example were to be made more accurate. There may well be more.So this shows that this is only to be treated as an example - though a very good illustrative one. Something more accurate is more likely, I think, to be achievable in the near term if it is a lot more simple and modular(as I started with the Invoice definition).