[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: semantics in schema (xsd)

• To: 'Pedro Salazar' <pedro-b-salazar@p...>, Irene Polikoff <Irene@t...>
• Subject: RE: semantics in schema (xsd)
• From: "Bullard, Claude L (Len)" <clbullar@i...>
• Date: Fri, 27 Feb 2004 11:35:28 -0600
• Cc: xml-dev@l...

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@p...]

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.  

• Prev by Date: RE: semantics in schema (xsd)
• Next by Date: - unsubscribe
• Previous by thread: RE: semantics in schema (xsd)
• Next by thread: RE: semantics in schema (xsd)
• Index(es):
  • Date
  • Thread