Forum OpenACS Development: Re: Comments on the new postal-address module (and kin)

Collapse
2: Re: Comments on the new postal-address module (and kin) (response to 1)
Posted by Jon Griffin on 05/28/03 05:34 PM
Alfred, Thanks for the comments. The changes for address and phone will only map to HR-XML and people can add packages as they see fit using these as a base. There will also be a slight change to the data model in 5.0 (easily backported to 4.6.x)

Telecom-number and postal-address are services. They are not packages. They are analogous to the reference-* packages. People are free to use the underlying data model as they see fit.

Everything you describe can be accomodated with the HR-XML framework. The reason other packages use seperate data is historical; The original address book was almost useless beyond a personal list and was most definitly hardly internationalized. Plus, many package designers just added their own tables without regard for what was already in the toolkit (states and countries come to mind).

My contacts-lite package is just that. It was (like much of the code here) written for a client who was kind enough to let me release it to the OACS community. It does however show how to use the underlying services (although certainly not everything has been completed, I have other obligations and they don't involve these packages anymore except for my personal use).

As anyone who has followed my posts on reference data and contacts in general knows, I am very concerned with internationalized contact information. Modelling these packages after HR-XML fulfills this need.

Collapse
3: Re: Comments on the new postal-address module (and kin) (response to 2)
Posted by Alfred Werner on 05/28/03 06:55 PM
I guess my biggest concern regarding how its currently implemented is that you are embedding the person into the address record - which is correct according to the HR-XML PostalAddress spec (PDF) but even that spec is clear on keeping the recipient isolated from the delivery address - page 15 cites several implementation considerations that I think are right on target.
Recipent is optional because many business processes store the intended recipient name separately from postal address. If your schema handles the recipient information elsewhere, avoid redundancy by not populating Recipient in PostalAddress elements. ‘Care Of’ data should be part of the DeliveryAddress, not part of Recipient. When using ‘care of information, it should be held in the AddressLine element to avoid problems when building the address.
etc. Look at page 15 and you'll see what I'm talking about. The Postal Address Spec is a core data spec in the HR-XML suite - if you look at items like Credit Report, Background Check, Contact Method, etc - they all have references to Postal Address - it seems redundant and potentially dangerous to store the Recipient with the Address in all cases, which is indeed how the postal-address package is designed.

I think much better is to refactor the people out from the address table entirely and use a join table to point people to addresses in all instances of the system. This does not prevent using HR-XML for data interchange, which is I assume your primary purpose.

I totally agree with your comment that this is a service like a reference package. I would go even further and get into a discussion of datatypes - I think that "address" is a specific datatype - in the sense that there is a specific 'range' of values (in the functions sense of the word) that are legal - there are well-formed addresses that are valid and well-formed addresses that are not valid.

The real "function" comes into play when you pair the people with the addresses at a given point in time - given the domain of people,date what is the address? I personally like this kind of design. Ideally, with no speed or memory constraints, you design it like this: table person ( name varchar(whatever), address varchar(whatever) Check address in (1 main st charlotte nc 11111,2 main st charlotte nc 11111, 3 main st charlotte nc 11111) etc :) or the 'references addresses' equivalent of it, in which case you just use an address_id and point to the address table.

Or we can just use usca_p cookies and call it a day!