Re: [ubl] Comment about UBL 2 Ordering Process diagram

[Stephen Green <stephen.green@documentengineeringservices.com>]

Hi Tim

Maybe this diagram isn't much use without me say re-doing all
the activity diagrams with the tool I use to make them consistent
in formatting. I've included an XMI file as well as jpeg, in case
you have the tool used for the original diagrams with the ability
to import XMI into it without losing too much - to make the diagram
consistent with the others.

Let me know if there's more I can do to help. I hope this diagram
is clearer in terms of the paths through it not having ambiguities.
I notice a few minor issues still but it is just a diagram, no more.

Best regards

Steve

2009/1/6 Stephen Green <stephen.green@documentengineeringservices.com>:
> Yes, of course, I should produce another diagram. Won't look like
> format of existing one so needs another edit pass at least to bring
> format in line with other diagrams.
>
> 2009/1/6 Tim McGrath <tim.mcgrath@documentengineeringservices.com>:
>> I think i agree with you but are your proposing updating the diagram?  i
>> would like to see your version of the process diagram.
>> Stephen Green wrote:
>>>
>>> I was asked recently abbout the Ordering process of UBL and I mention
>>> a couple of comments since things are moving toward UBL 2.1 and maybe
>>> the speec could be improved with a little clarification on Ordering.
>>>
>>> I note first that we did of course agree that UBL 2.0 would not limit
>>> the schema uses regarding the processes outlined:
>>>
>>> To quote the UBL 2.0 spec
>>> Section 4: UBL 2.0 Context of Use
>>> http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html#CONTEXT
>>> "The processes described in this section, and the business rules
>>> associated with them, define a context for the use of UBL 2.0 business
>>> documents. They are normative insofar as they provide semantics for
>>> the UBL document schemas, but they should not be construed as limiting
>>> the application of those schemas."
>>>
>>> This means the Ordering process isn't described as a limitation on the
>>> processes used with any UBL Ordering schema.
>>>
>>>
>>> The spec does seem to be ambiguous about the Ordering process.
>>> [Below I refer to processes completing when I say 'completion' not to
>>> be confused with the order itself being 'completed' - the process could
>>> 'complete' even with a cancellation of the order.]
>>>
>>> According to the UBL 2.0 spec
>>> "Figure 8. Ordering Process"
>>> http://docs.oasis-open.org/ubl/os-UBL-2.0/art/UBL-2.0-OrderingProcess.jpg
>>>
>>> the ordering can complete in several ways which depend on which document
>>> is used to respond to the order. If an OrderResponse is the document sent
>>> in response then there are three ways to complete:
>>>
>>> 1. if the OrderResponse is sent without any modification then the order
>>> can
>>> be completed by Buyer doing nothing (except of course sending signals
>>> where
>>> appropriate e.g. with ebXML)
>>>
>>> 2. if the OrderResponse is sent with modification then there are two ways
>>> to complete the process
>>>
>>> 2a. Buyer send an OrderCancellation
>>>
>>> 2b. Buyer send an OrderChange
>>>
>>>
>>> An order rejection by the Seller is typically performed using the
>>> OrderResponseSimple. I'm not sure it *can* be done using the OrderResponse
>>> document schema without customizing the schema.
>>>
>>> What isn't clear from the diagram is how the different responses relate to
>>> the
>>> different paths to completion. The diagrams might be clearer and less
>>> ambiguous about paths to completion if the 'ReceiveResponse' box was split
>>> into two or more boxes showing how different kinds of response determine
>>> different process paths. The ReceiveReponse should only lead to the
>>> 'accept
>>> order?' gateway (yes/no) if the OrderResponse did *not* include any
>>> modifications
>>> otherwise how is the Seller to know whether the modifications were
>>> accepted?
>>> It isn't clear about this. Neither exit from the gateway requires any
>>> further
>>> message to the Seller. Really it only makes sense if the diagrammed
>>> Documents
>>> prior to the 'ReceiveResponse' task are more specific. An OrderResponse
>>> with
>>> modifications ('AddDetail' followed by OrderResponse document in diagram)
>>> has to be shown following a different path to an OrderResponse without
>>> modifications ('Accept Order' followed by OrderResponse) and different
>>> again
>>> from a rejected Order ('Reject Order' followed by OrderResponse). In the
>>> latter
>>> case I would suggest only OrderResponseSimple can follow the 'Reject
>>> Order'
>>> task, by the way, though I might be corrected on that. I don't think an
>>> OrderResponse can be used to reject an order outright can it? Not without
>>> customisation?
>>>
>>>
>>>
>>>
>>> Best regards
>>>
>>>
>>
>
>
>
> --
> Stephen D. Green
>
> Document Engineering Services Ltd
>
>
>
> http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
>



-- 
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice

UBL-2.1-OrderingProcess.JPG

ubl2-1Ordering.xmi