[
Lists Home |
Date Index |
Thread Index
]
The programmer is not empowered to legislate relationships. A
customer may need to record relationships that are valid under the
law. Because the law varies by locale, so must the relationships
within the software (people is people: relationships are codes
as far as the programmer's authority or power reaches).
A typical technical approach is to create an enumerated
code list of the relationships that qualify under the business
rule. Note that 'marriage', not the gender is the issue.
The real dilemma, is of course, co-occurrence constraints.
So while under California statutes for a 'marriage license',
a homosexual relationship is not a valid enumerated relationship
for marriage, at this time, under the police data base of related
names, this is possible.
Here is a typical set of 'name' and "related names" values for a named
person
in a police database. I note where the set is extensible by enumeration.
Names:
1. Sex: Male, Female, unknown.
2. Marital: Married, Single, Divorce, Other, Unknown
3. Co-habitation Flag (for related names).
Related Names:
If a named person is related to a named person, the
related names entity is used. It includes an enumerated
list of recognized relationship codes. These are code
lookups, not objects or classes. Codes are really
what this is about, not objects or classes.
Sibling, Step-child, Spouse, Step-parent, Step-sibling,
Other family member, Otherwise unknown, Parent,
Relationship Unknown, Acquaintence, Babysittee,
Boyfriend/Girlfriend, Child of Boyfriend/Girlfriend,
Child, common-law spouse, employee, employer, friend,
grandchild, grandparent, homosexual relationship,
in-law, neighbor, stranger, offender, ex-spouse.
The problem of course here, is that the relationship can
be several of these at once, and that where you will
hit these in schematron is in the co-occurrences.
I suggest that be extensible.
len
From: Pedro Salazar [mailto:pedro-b-salazar@ptinovacao.pt]
Now, the discussion has clarified me about the importance of the
definition schema, and believe me that I abandoned the theory of trying
to validate the most as possible with the schema rules.
I agree that the schema should be simple, and the semantics validations
should be done post-schema validation. I mean, I'll try to use
schematron (for instance) to do the post semantics validations and keep
my schema definition stable and simple.
|
