OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: FW: PRO03 Transport Documentation Review for Intermodal Freight Management


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]