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] UBL 1.0 draft 4 models in hand

There still seems to be a certain degree of arbitrariness in the model as to what constitutes a Property Term Adjective, as distinct (if at all) from a Property Term Noun. 
E.g. in Commodity Classification we have Cargo Type Code and this is named with Cargo Type as a two part Property Noun whereas in Transport Equipment Seal we have Issuer Type Code and in this case 'Issuer' is in the separate column as a Property Term Adjective with 'Type' as the Property Term Noun.
For now, correct me if necessary, not really understanding any distinction between these forms, I'll use the Adjective column for the second 'adjective-like' part of the term (concluding that perhaps the extra column was added after the likes of Cargo Type were named and the latter not split between columns). 

All the best

>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 09/21/03 14:32 PM >>>

Sorry I was out of touch yesterday. The models are in hand. I've made the necessary changes to the GUID. I have only changed the Rep' term to 'Globally Unique Identifier' and changed the formula for column A to 

=SUBSTITUTE(SUBSTITUTE(CONCATENATE(E5;F5;IF(G5<>K5;G5;"");CONCATENATE(H5;IF(I5="Identifier";"ID";IF(I5="Text";"";IF(I5="GloballyUniqueIdentifier";"GUID";I5)))));" ";"");"'";"")

I've a few questions - the last of which is the most important:

1) Should I change the formula for column K? It is currently:
=IF(AND(OR(G6="Identification";G6="ID");I6="Identifier");G6;IF(AND(OR(G6="Time";G6="Date");I6="Date Time");G6;I6))

2) In line with 1) I wondered if there might be an error in OrderCancellation where we have Date Time used. Here the data type still says 'Date', not Date Time (column K)

3) The most mportant matter is concerning the codelists again. Because of our mechanism (or perhaps just the nature of codelists themselves, to be more analytical) we have, it seems, to have a unique UBL name for each Code using a particular codelist. For example, we have different TypeCode entities, each using a separate codelist but they should have separately unique UBL Names so I feel I must try to qualify say 'CardAccount. TypeCode' to distinguish it from, say, 'TaxScheme. TypeCode'. Otherwise, there would be more than one TypeCode to reference in the reusable schema which isn't possible. They would end up as having the same codelist for each TypeCode which would obviously be wrong. Now the matter is not helped by our naming rules which do not seem to allow duplications of name parts. So I have to find a qualifier for 'CardAccount. TypeCode' other than 'Card' or 'Account' or we would have 'CardAccount. CardTypeCode' for te new name 'CardTypeCode'. Would the latter be OK? 

For now I will just do my best with qualifiers.  

Beyond this I hope we have time to re-examine how our Order/OrderResponse system is working and get it sorted. Tim: I'm wondering why we seem to have no Acceptance or Rejection codes or indicators in the complex response when we have them in the simple.

All the best


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.

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