[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Comment about UBL 2 Ordering Process diagram
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]