[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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_workgrou >>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_workgrou >>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_workgroup.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]