No Subject

On b) - Agree with you here Tim. The line implementation is not the best
choice. In Finance A text element format AN 140 is chosen. I believe this is
the best!

c) the implementation could be of type XOR!


Best Regards

Stig Korsgaard
M.Sc.E Standardisation Coordinator
Tel: 	+45 3370 1083
Cell: 	+45 2121 8234
Mail: 	stk@finansraadet.dk

Danish Bankers Association
Amaliegade 7
DK-1256 Copenhagen K
Tel:	3370 1000
Fax:	3393 0260
mail@finansraadet.dk
www.finansraadet.dk 



-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: 4. juli 2003 04:32
To: ubl-LCSC@lists.oasis-open.org
Subject: [ubl-lcsc] [roe] OAG Comment: Structured vs. Unstructured
Address 


To facilitate debate and consensus on the reviewed items, I am posting 
relevant issues as discussion points.  The intention is that after a one 
week period the team shall resolve these issues.  For example, this 
issue will be resolved at the call on Friday July 11th.

Item 6.

OAGIS has concluded that address line detail information has been widely 
implemented using one of two methods - a structured method where each 
property of an address line (e.g. house number, street name, unit) is 
captured as separate data elements [this is the current UBL method] or 
an unstructured method where address line 1, address line 2, etc. is 
captured as a string of text.  Both methods are perfectly valid and 
forcing one method as the standard (while preferable from a standards 
perspective) would be extremely burdensome for a large number of 
existing applications.

As a compromise position, OAGIS has implemented a xsd choice group which 
allows users to select either method but not both.  Choice groups are 
quite useful in these situations and while they are not specifically 
mentioned in CCTS v1.90, they are not expressly prohibited either.

There are three issues here:

a. Do we accept the need for unstructured address information?
b. is the line1, line2, line3, etc. approach the best way of doing this? 
 For example, the proposed alternative is not truly unstructured as it 
requires presentation structure (what goes on line 1, line 2 etc..). 
 truly unstructured would just be a text that is called AddressText.
c. How do we describe choice (e.g. may have either, but must choose one) 
in our spreadsheets?

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160



You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgrou
p.php