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 sets for Document and LineItem Status


After having spent some time looking for code list values on the web 
recently
I would propose that we want to keep a safe distance from creating the 
appearance
that we are maintaining code lists in any way.  Some of the suggested 
changes
below may take us too much in that direction  - might make it appear as 
though
we are maintaining these codes, since it will be obvious looking at the 
values that
we have changed them.

Hopefully the TC that Jon mentioned will come about sooner than later.
I'm finding this area to be a real morass of overlapping, mutable efforts,
where ownership is already unclear except for a very, very few instances.
At this point I'm even more inclined to suggest that we step away from this
area as much as possible, except for the few codes that are absolutely
necessary to meet the requirements that our basic model needs for
generic implementation and processing, since anything we do here
is likely to step on someone's toes.

-A

Tim McGrath wrote:

> My call is that we do not want to impose any restrictions or 
> presentational rules on the content of any documents.  This includes 
> character case .
>
> These are decisions for applications to make.  Bear in mind UBL is not 
> standardising on what goes in  documents only the semantics and 
> structure.  We actually crossed a boundary when we starting looking at 
> determining code set values (for good reason) but we dont want to go 
> any further than necessary.
>
> You can guarantee that any formatting rules we make would break 
> someone's requirements.
>
> PS the same applies to facets like "XXX-XXX-XXX" for account number, 
> etc...
>
>
> Chin Chee-Kai wrote:
>
>>Do we need a rule to make all code list values look uniformly
>>upper-cased?
>>
>>It appears the various code list values, when compared
>>across various code list schemas, appear to have Upper Camel
>>Cases, with some having spaces in between multiple-worded values.
>>
>>We may need to require implementation rules, for instance,
>>that when code list values are implemented in schemas,
>>they should go through the following transformations:
>>
>>
>>(Example shown is somewhat contrived to illustrate how the
>>transformation rule works.)
>>
>>1. Remove all punctuations, except "-", and compacting the
>>   resulting string.  Multiple spaces would be reduced to a 
>>   single white space, and remove prefixing and trailing
>>   spaces (required by base type xsd:token)
>>
>>   E.g.   "New  York's  Philharmonic Orchestra    ---  Class A"
>>   -->    New Yorks Philharmonic Orchestra --- Class A
>>
>>
>>2. Replace multiple occurences of "-" with a single hyphen.
>>
>>   E.g.   New Yorks Philharmonic Orchestra --- Class A
>>   -->    New Yorks Philharmonic Orchestra - Class A
>>
>>
>>3. Replace any occurence of the sequence " -", "- " and
>>   " - "  (space followed by hyphen, or hyphen followed by 
>>   space, or space followed by hyphen followed by space)
>>   with just hyphen "-".
>>
>>   E.g.   New Yorks Philharmonic Orchestra - Class A
>>   -->    New Yorks Philharmonic Orchestra-Class A
>>
>>
>>4. Replace any occurence of space " " with "-"
>>
>>   E.g.   New Yorks Philharmonic Orchestra-Class A
>>   -->    New-Yorks-Philharmonic-Orchestra-Class-A
>>
>>
>>5. Replace all characters with their equivalent uppercase.
>>
>>   E.g.   New-Yorks-Philharmonic-Orchestra-Class-A
>>   -->    NEW-YORKS-PHILHARMONIC-ORCHESTRA-CLASS-A
>>
>>
>>
>>
>>Best Regards,
>>Chin Chee-Kai
>>SoftML
>>Tel: +65-6820-2979
>>Fax: +65-6743-7875
>>Email: cheekai@SoftML.Net
>>http://SoftML.Net/
>>
>>
>>On Wed, 15 Oct 2003, Stephen Green wrote:
>>
>>  
>>
>>>>Hi
>>>>
>>>>...
>>>>
>>>>I'd suggest just 
>>>>
>>>>'No Status'
>>>>'Revised'
>>>>'Withdrawn' 
>>>>(but I'd rather 'Cancelled' which we don't seem to have here) 
>>>>and
>>>>'Disputed'
>>>>
>>>>      
>>>>
>>>>from UN/CL 4405
>>>    
>>>
>>
>>  
>>
>
>-- 
>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]