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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


Subject: RE: [ubl-lcsc] Code list content review


Anne, Tim et al

I don't believe we should change any values now and I apologise if my
comments have started discussions again - let's agree finally that the
current set of lists are the 1.0 lists.

I also remember all the earlier discussions and efforts and, as we all know,
code work can always take longer but we really do need to draw a line where
we are right now.

cheers

Sue

-----Original Message-----
From: Anne Hendry [mailto:anne.hendry@sun.com]
Sent: 15 March 2004 22:21
To: Tim McGrath
Cc: Sue Probert; Ubl-Lcsc; dill2@gefeg.com; David Kruppke
Subject: Re: [ubl-lcsc] Code list content review


My previous response came before I read this one, so here are a couple
more comments.

Regarding the document and line status codes, no, if you look at the
definition of cancelled (actually there is no simple 'cancelled in 1229,
there's 'cancellation (of previous message)' and 'cancel, to be
reissued', in 1229 theres 'cancelled, due to lack of acitivty' , and
'cancelled, discontinued', neither of which fit, but the closest we
could find to what we needed there was 'closed, shut', and we didn't
like that, then 1373 has no cancelled at all, just 'rejected'.   None of
them mean the same thing as what we mean by 'cancelled'.  Also, one of
those in our list was not in either of the 3 un lists you mention.
 Believe me, we tried this and spent a lot of time on it.  These lists
for the most part do not represent the meaning we need to convey.  At
first glance they seem great, but once you just scratch the surface you
find they are very seldom for the purpose we intend.  So, no, these are
not subsets, as Tim states, they are UBL codes not based on the un
codes.  We tried, and spent a lot of time back and forth on these, but
we couldn't, in the end, make them work to our satisfaction.   And yes,
another concern was that they were too large, although this was a minor
concern related to the difference in intended meaning that they
conveyed.  I agree that we can look at this after 1.0 and see if there
is something else available, but I would not agree to change these now
at this late date knowing how much effort went in to deciding these
current values to begin with.

In your question about some of the code types being more like
indicators, it was my understanding that the reason indicator wasn't
used is that ccts (table 8-3) defines indicator as two mutually
exclusive boolean values, and that this was being mapped to xsd:boolean
in the schemas (it is defined as "A list of two mutually exclusive
Boolean values that express the only possible states of a Property" in
the unspecialized dt schema).  xsd schema only allow True, False, 0, or
1 (if you use a facet).  So these are not really indicators (to my
knowledge).  They are just two values.  Tim, correct me if I'm wrong
here as I'd like to understand this better myself, but would it even be
possible to use 'Indicator' for something like 'East'/'West'?  How do
you map that to boolean?  It woudln't be very intuitive, would it be?

Thanks,
Anne


Tim McGrath wrote:

> we did all spend a lot of time of document status and line status
> codes and i am happy what you see is the group consensus.  if it is
> not a restriction on the UNCL code then so be it.  I now recall we
> simply tried to align the terminology with these lists.
>
> i can also comment on your last comment.  we use the code list
> mechanism to establish fixed sets of values for a BBIE.  in other
> words if we want an enumerated list - we call it a code.  it is a
> terminology issue.  what we are calling a code list mechanism is
> really an enumerated lists mechanism.  we do use it for codes but it
> could be for other types of BBIEs as well. i think Gunther has already
> mentioned identifiers ;-)
>
> Sue Probert wrote:
>
>>Hi Tim
>>
>>Yes, Edifix does have all these UNCL codes internally available. The only
>>thing I had to check was which version of UNCL the UBL list equated to -
>>this is the D03A directory version.
>>
>>The concern I have with regards to the line status and document status
codes
>>is that I cannot find all the UBL values in the UNCL appropriate lists
which
>>are 1229 for line status codes and 1225 or possibly 1373 for document
status
>>codes. Some certainly match up such as 'cancelled' but others are missing
or
>>not exact matches. I guess that we can deal with this later. Edifix can
>>subset code lists for EDI guidelines but I am not sure how this works for
>>schema use.
>>
>>Finally, your proposal for the remaining code lists should be fine, I
guess.
>>However, I am left wondering why these are code lists at all as they seem
>>like pairs of indicator values. Again a question for later on, I suppose.
>>
>>regards
>>
>>Sue
>>
>>-----Original Message-----
>>From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
>>Sent: 15 March 2004 08:20
>>To: Sue Probert
>>Cc: Ubl-Lcsc; dill2@gefeg.com
>>Subject: Re: [ubl-lcsc] Code list content review
>>
>>
>>I assume when you say "OK to use full list from EF", you mean that
>>EDIFIX already has these codes and they don't need anne's (hard won)
>>text files!?
>>
>>As for the other issues...
>>
>>If you remember the discussion  on DocumentStatusCode and
>>LineStatusCode, i think the concern was that the UNCL code lists were
>>too big - we want to limit those used to the 4 Document Statuses and 5
>>Line Statuses only.  So these are a restriction on the UNCL code lists.
>>
>>CargoTypeCode was only a 'placebo' and we are implementing 'standard
>>(and stock)' codes for the 1.0 package - so it is left undefined.
>>
>>With ChipCode , OperatorCode and SubstitutionStatusCode  the names have
>>not yet been added - because we have none.  i propose that the names are
>>the same as the code value (the CodeContent). for example,
>>OperatorCode.Content = "multiply" and OperatorCode.Name="multiply"
>>
>>w.r.t. the EDIFIX code values, we have to think about maintenace of
>>these values - so it would still help to have import and export of this
>>data sorted out, rather than rely on manual entry and checking.
>>
>>
>>Sue Probert wrote:
>>
>>
>>
>>>Hi All
>>>
>>>Firstly, apologies for missing the calls last week due to the CEFACT
Forum
>>>meeting. I have nevertheless been following the email threads, or at
least
>>>trying to do so.
>>>
>>>Over the weekend I have checked the latest text files from Anne against
the
>>>latest codes spreadsheet from Tim and the following is my synopsis of the
>>>current 'code content' situation.
>>>
>>>AllowanceChargeReasonCode - codes are from UNCL 4465 D03A - OK to use
full
>>>list from EF
>>>ChannelCode - codes are from UNCL 3155 D03A - OK to use full list from EF
>>>PaymentMeansTypeCode - codes are from UNCL 4461 D03A - OK
>>>(CargoTypeCode - codes are from UNCL 7085 D03A - OK but this code list
>>>appears to have disappeared?)
>>>
>>>CurrencyCode - ISO 4217 - OK to use full list from EF
>>>
>>>AcknowledgementResponseCode - 2 codes made up by UBL - names now added
>>>LatitudeDirectionCode - 2 codes made up by UBL - names now added
>>>LongitudeDirectionCode - 2 codes made up by UBL - names now added
>>>DocumentStatusCode - 4 codes made up by UBL - names now added (UNCL 1225
>>>could be used?)
>>>LineStatusCode - 5 codes made up by UBL - names now added (UNCL 1229
could
>>>be used?)
>>>
>>>ChipCode - 2 codes made up by UBL - names not yet added
>>>OperatorCode - 2 codes made up by UBL - names not yet added
>>>SubstitutionStatusCode - 2 codes made up by UBL - names not yet added
>>>
>>>Tim and Anne, do you agree with this?
>>>
>>>regards
>>>
>>>Sue
>>>
>>>
>>>
>>>To unsubscribe from this mailing list (and be removed from the roster of
>>>
>>>
>>the OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgr
ou
>>p.php.
>>
>>
>>>
>>>
>>
>>--
>>regards
>>tim mcgrath
>>phone: +618 93352228
>>postal: po box 1289   fremantle    western australia 6160
>>
>>
>>
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster of
the
>>OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgr
ou
>>p.php.
>>
>>
>>
>>
>>To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgrou
p.php.
>>
>>
>>
>
>--
>regards
>tim mcgrath
>phone: +618 93352228
>postal: po box 1289   fremantle    western australia 6160
>
>
>




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