Talk:Modeling LID--The classes and associations of the model

From LID Wiki

Changes and discussion of same

1. The element, IdentityDataItemRole was at first named IdentityDataItemQualifier. I gave this rationale:

"(I admit it: here i split between Type (see communityUML 5.4.1) and Qualifier. Q: Why? A: Because a qualifier, rather than telling us anything about the item itself, tells us how the item is intended to be used: that's my short answer. A: For a slightly longer answer, note that RFC 2426 says that 'TYPE' is the name of a paramater; it does not refer to the category of MIME types, nor is it a new MIME type. (Naming this parameter 'TYPE' is confusing at best (but we are not here to criticize our betters).))"

But it occured to me that what i classified as vCard field qualifiers are roles of the vCard fields.

I believe 'role' is correct here. Consider a delivery address: Q: What is the role of this address? A: This is the address to be used for work mail. Or telecomm addresses: Q: What is the role of this address? A: This is the address for personal faxes and for personal phone calls when i am at home.

Notice that 'role' fits what i wrote at first about 'qualifier': "tells us how the item is intended to be used"

See also vCard field roles.

2a. We will need grouping within anIdentityData, for example to group the fields of an address. My first inclination was to add IdentityDataGroup, distinct from IdentityData, with the composition being from IdentityDataGroup and IdentityData being a subclass of IdentityDataGroup. But that offended my lumping instincts. I believe we can eliminate IdentityData. [RFC 2426] shows us how to distinguish the vCard from a group of items, by providing the field, profile.

2b. So i intended to change the name of IdentityData to IdentityData group. I went to the article to do that and... Hey. No reason to change the name. This will all be handled by additions to the list of roles.