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

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

Greetings UBL TC

RE: Order Process Diagram

Prior to UBL TC discussion of this, I thought I'd better add my own two cents
worth: I realise the ordering process doesn't attempt or claim to show all the
aspects of real-life use of the UBL ordering documents (e.g. no attempt to
show that an order can be cancelled prior to order response). I agree my
diagram version does seem to remove some possibilities but does this matter
if it is a clarification? Maybe the things it removes can be added back in
without obscuring anything. At the same time it should be considered
1. include a cancellation before the order response
2. there is a cycle (pointed out as we tried to use this diagram in TAG TC)
which might need consideration - going from order 'modified' to order
change and back to possible modification and so on - is this realistic?
The aim with my modified diagram is only to improve the clarity (with paths
through the process not sharing so many steps - different paths having their
own steps , even if those steps have the same names). I didn't attend to create
a profile as such. Nothing should be missing that is in the original,
just clearer
paths. Maybe add order cancellation prior to response and qualify the loop(s).

Best regards

Steve


2009/1/14 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
>



-- 
Stephen D. Green

Document Engineering Services Ltd



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