OASIS Universal Business Language (UBL) TC

Hi all, These last few days we have been discussing the addition of codes to the DocumentStatusCode list in TSC. In the document Transport Execution Plan we have defined a set of codes to be used in defining this document's status in the interaction between the Transport User (the role for parties requesting a transportation service) and the Transport Service Provider (the role for parties providing transportation services). Essentially the question is whether we should merge the following codes into the DocumentStatusCode list: Confirmed: The proposed Transport Execution Plan/Transport Execution Plan Request is confirmed by the sending party. Not Confirmed: The proposed Transport Execution Plan/Transport Execution Plan Request is not confirmed (nor rejected). Rejected: The proposed Transport Execution Plan (including updates and cancellations) is fully rejected. Updated: The original Transport Execution Plan is updated. Cancelled: The Transport Execution Plan (already confirmed by both parties) is proposed cancelled. Completed: The services covered by the Transport Execution Plan have been completed. Comments on this are welcomed... Regards, Audun Audun Vennesland  Research Scientist SINTEF ICT   Intelligent Transportation Systems   audun.vennesland@sintef.no  +47 928 94 418 mobile  +47 73 59 29 37 office  Skype: audun.vennesland www.sintef.no

I notice we have no DocumentStatusCode in the draft 2.1 package. So what are we adding too? The 2.0 DocumentStatusCode had Cancelled, Disputed, NoStatus and Revised. So it seems we need to rationalize not just add (for backward compatibility). Also the 'Not Confirmed' should be 'NotConfirmed' to be consistent. No reason why we should not use embedded space but we should be consistent. On 26/03/12 8:21 PM, Audun Vennesland wrote: Hi all, These last few days we have been discussing the addition of codes to the DocumentStatusCode list in TSC. In the document Transport Execution Plan we have defined a set of codes to be used in defining this document's status in the interaction between the Transport User (the role for parties requesting a transportation service) and the Transport Service Provider (the role for parties providing transportation services). Essentially the question is whether we should merge the following codes into the DocumentStatusCode list: Confirmed: The proposed Transport Execution Plan/Transport Execution Plan Request is confirmed by the sending party. Not Confirmed: The proposed Transport Execution Plan/Transport Execution Plan Request is not confirmed (nor rejected). Rejected: The proposed Transport Execution Plan (including updates and cancellations) is fully rejected. Updated: The original Transport Execution Plan is updated. Cancelled: The Transport Execution Plan (already confirmed by both parties) is proposed cancelled. Completed: The services covered by the Transport Execution Plan have been completed. Comments on this are welcomed... Regards, Audun Audun Vennesland Research Scientist SINTEF ICT Intelligent Transportation Systems audun.vennesland@sintef.no +47 928 94 418 mobile +47 73 59 29 37 office Skype: audun.vennesland www.sintef.no
Original Message----- From: G. Ken Holman [ mailto:g.ken.holman@gmail.com ] On Behalf Of G. Ken Holman Sent: 25. mars 2012 12:43 To: Audun Vennesland; Jon Bosak Cc: Andrew M Schoka; Tim McGrath Subject: RE: FW: PRO03 Transport Documentation Review for Intermodal Freight Management At 2012-03-25 10:21 +0200, Audun Vennesland wrote: These are codes used for tracking the status of a Transport Execution Plan in the interaction between the Transport User and Transport Service Provider. So these codes will only be used by the Transport Execution Plan. We initially used a BBIE TransportExecutionPlanStatus in relation to these codes, but then discovered the existing DocumentStatus BBIE which we considered a better solution since we then re-used an existing UBL entity instead of inventing a new one. As the DocumentStatus BBIE in UBL 2.0 has a data type qualification, that being the committee-assigned code list of values used in the XSLT pass of value checks, your choice has implicitly brought in that value validation for the BBIE. Regarding your question on formal data type qualification I am not really sure how to approach this, especially since the DocumentStatusCode list is already defined as a UBL code list (we didn't know that when we decided to change from TransportExecutionPlanStatus to DocumentStatus). In the Intermodal Freight Management documents we already use a number of code lists that are not a part of UBL 2.1 so not including them as formal code list values wouldn't pose a problem as such. A side question: should any of these code lists be provided for UBL 2.1 users in the special-purpose directory as a convenience to users? http://docs.oasis-open.org/ubl/prd2-UBL-2.1/cl/gc/special-purpose/ Could the DocumentStatusCode list be modified to support the proposed Transport Execution Plan codes? I assume it is easier to add the codes that are new (Confirmed, Not Confirmed, Rejected, Completed) than change the ones that already exist (Cancelled, Revised/Updated)?! Indeed it is easier to add such values to our "standard" code list ... however doing so would also add those values in the procurement contexts of using this BBIE. Which may not be a problem at all, but the values would then be available. Would you agree that the four new values have distinctly different semantics than the ones that currently exist? http://docs.oasis-open.org/ubl/prd2-UBL-2.1/cva/UBL-DefaultDTQ-2.1.html#d12e1 If all your values are distinct, then PSC shouldn't have a problem with them being added as it won't interfere with any expectations for procurement. I see no problem extending the list as someone with "pure" procurement in mind can choose to subset the UBL 2.1 list to the UBL 2.0 subset in their application of UBL in their environment. So, I see no problem, but I think your question and my answer should be visible to the entire TC in order to open the debate for others to comment on for the very short period we have before the next snapshot. Can you distill the above question and answer into a post for the TC list that solicits input from others? Interestingly, a quick page through all of our code lists would indicate that the proposed new value "NOT CONFIRMED" would introduce our first code that includes a space character. This is fine, as single spaces are allowed in the data type for code lists. This is also fine in that it could be held up as an example to be cited of a code list value with a space. Or, could we use "UNCONFIRMED" as an appropriate value? Are the semantics of "unconfirmed" identical to "not confirmed" in your anticipated use and documentation of the value? In my Apple's copy of the New Oxford American Dictionary, "unconfirmed" is defined as "not confirmed as to truth or validity : an unconfirmed report of shots being fired." Thanks, Audun! . . . . . . . . . . Ken -- Contact us for world-wide XML consulting and instructor-led training Free 5-hour video lecture: XSLT/XPath 1.0& 2.0 http://ude.my/uoui9h Crane Softwrights Ltd. http://www.CraneSoftwrights.com/m/ G. Ken Holman mailto:gkholman@CraneSoftwrights.com Google+ profile: https://plus.google.com/116832879756988317389/about Legal business disclaimers: http://www.CraneSoftwrights.com/legal begin:vcard fn:Tim McGrath n:McGrath;Tim org:Document Engineering Services email;internet:tim.mcgrath@documentengineeringservices.com title:Managing Director tel;work:+61893352228 tel;home:+61438352228 tel;cell:+61438352228 url:www.documentengineeringservices.com version:2.1 end:vcard

At 2012-03-27 14:08 +1100, Tim McGrath wrote: I notice we have no DocumentStatusCode in the draft 2.1 package. So what are we adding too? The 2.0 DocumentStatusCode had Cancelled, Disputed, NoStatus and Revised. In PRD2 the DocumentStatusCode list was no different, so the PRD2 CVA file simply points to the UBL 2.0 version (note the URI): http://docs.oasis-open.org/ubl/prd2-UBL-2.1/cva/UBL-DefaultDTQ-2.1.html#d12e1 If we have a longer list for 2.1, then that longer list will show up in this directory: http://docs.oasis-open.org/ubl/prd2-UBL-2.1/cl/gc/default So it seems we need to rationalize not just add (for backward compatibility). Not sure what you mean by "rationalize" in this context. The 2.1 list would include both all of the old values (for compatibility) and all the new values (for new functionality) so as to be complete. Also the 'Not Confirmed' should be 'NotConfirmed' to be consistent. No reason why we should not use embedded space but we should be consistent. Good point! Thank you for making that observation, Tim. . . . . . . . . . . . . Ken -- Contact us for world-wide XML consulting and instructor-led training Free 5-hour video lecture: XSLT/XPath 1.0 & 2.0 http://ude.my/uoui9h Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ G. Ken Holman mailto:gkholman@CraneSoftwrights.com Google+ profile: https://plus.google.com/116832879756988317389/about Legal business disclaimers: http://www.CraneSoftwrights.com/legal

thanks for the explanation. By rationalize, as an example i meant that we already have a code for Cancellation - so we cannot add another one. On 28/03/12 1:33 AM, G. Ken Holman wrote: At 2012-03-27 14:08 +1100, Tim McGrath wrote: I notice we have no DocumentStatusCode in the draft 2.1 package. So what are we adding too? The 2.0 DocumentStatusCode had Cancelled, Disputed, NoStatus and Revised. In PRD2 the DocumentStatusCode list was no different, so the PRD2 CVA file simply points to the UBL 2.0 version (note the URI): http://docs.oasis-open.org/ubl/prd2-UBL-2.1/cva/UBL-DefaultDTQ-2.1.html#d12e1 If we have a longer list for 2.1, then that longer list will show up in this directory: http://docs.oasis-open.org/ubl/prd2-UBL-2.1/cl/gc/default So it seems we need to rationalize not just add (for backward compatibility). Not sure what you mean by "rationalize" in this context. The 2.1 list would include both all of the old values (for compatibility) and all the new values (for new functionality) so as to be complete. Also the 'Not Confirmed' should be 'NotConfirmed' to be consistent. No reason why we should not use embedded space but we should be consistent. Good point! Thank you for making that observation, Tim. . . . . . . . . . . . . Ken -- Contact us for world-wide XML consulting and instructor-led training Free 5-hour video lecture: XSLT/XPath 1.0 & 2.0 http://ude.my/uoui9h Crane Softwrights Ltd. http://www.CraneSoftwrights.com/o/ G. Ken Holman mailto:gkholman@CraneSoftwrights.com Google+ profile: https://plus.google.com/116832879756988317389/about Legal business disclaimers: http://www.CraneSoftwrights.com/legal --------------------------------------------------------------------- To unsubscribe, e-mail: ubl-unsubscribe@lists.oasis-open.org For additional commands, e-mail: ubl-help@lists.oasis-open.org begin:vcard fn:Tim McGrath n:McGrath;Tim org:Document Engineering Services email;internet:tim.mcgrath@documentengineeringservices.com title:Managing Director tel;work:+61893352228 tel;home:+61438352228 tel;cell:+61438352228 url:www.documentengineeringservices.com version:2.1 end:vcard