One of HR-XML’s big challenges is people — or more specifically how to model them. HR-XML needs to represent human resources — and a variety of their “designees” — in a variety of contexts and roles: employee, candidate, contractor, subscriber, account holder, assessment subject, screening subject, appraisal subject, supervisor, dependent, beneficiary, etc.
People are amazingly complex and information requirements across the HR services domain are amazingly diverse. Compounding the problem is that XML, the syntax HR-XML currently uses in expressing its data model, has a few limitations that can make managing complexity challenging. As mentioned in a recent post, one of those limitations is that there isn’t an elegant, XML-native way to sub-class a larger superclass. So there isn’t an easy way to say that something like “Assessment Subject Person” or “Plan Participant Person” is a sub-class of a broader Person or Human Resource object class and that the sub-class uses a narrower, specialized set of components from the superclass. Within XML schema, it’s easier to build things up from bits and pieces than it is to restrict something larger down to something smaller.
Global Scoping: Changes to Our XML Library
One concession to the “bits and pieces” nature of XML schema, is that HR-XML 3.0 will make most components globally scoped — both aggregate components as well as field-level components. This will give us much more control in developing a consistent model across our dozen or so sub-domains. Note that what is an advantage at design-time, poses other issues at implementation (See Less is More: Flattening, Profiling, Slimming). Within the 2.* HR-XML architecture, reuse was mainly managed through the sharing of discrete “Cross Process Objects.” In 3.0, everything is shared. We are moving HR-XML specifications out of the sub-domain silos, componentizing them, reconciling them, and putting them into a single model.
HR-XML 3.0 will still be a library of XML schemas. It will not truly be “model-driven” in the sense of being independent of XML syntax. However, the HR-XML 3.0 project does take us in the direction of a syntax-neutral, model-driven library. The Core Component Technical Specification (CCTS) provides us with the framework for constructing that syntax-neutral model. CCTS is quite a weighty topic that I can’t cover in a blog post, but suffice it to say that core component analysis layered over our re-factored XML library gives us an important way to manage our “people problem.”
CCTS’s Data Element Model and Sub-Classing
CCTS uses a “data element name” (DEN) modeling convention set out under ISO 11179-5. Under that convention, a data element name (not necessarily the physical, HR-XML 3.0 tag name) is composed of an: object class term, a property class term, and representation term (in order). The notation for DENs relies on a period (“.”) to separate the three types of terms. DENs also may include “Qualifier” terms. These may be attached to narrow or refine object class terms, property terms, or representation terms. Under the notation for DENs, qualifier terms are specified with an underscore suffix (“_”).
Consider the above core-component approaches in light of what I mention about XML in the third paragraph. What the core component approach gives us is a way to think about and manage the sub-classing that XML doesn’t really provide natively. With regard to HR-XML’s “people problem,” the core component approaches give us a way to manage information about people across our library, without having to resort to a monolithic, “one-size-fits-all” model or, conversely, a set of siloed, fragmented specifications.
Applying CCTS to the HR People Problem
Within the human resource context, there is — at least conceptually — a huge, all encompassing “Person. Details” class. This may never be instantiated in the HR-XML library, but this class is useful to think about as a foundational, abstract class that has everything anyone would want to know about a person within an HR context. This superclass would be restricted or qualified in a variety of ways across our library. Consider the following examples (using the DEN notation introduced above).
- Subscriber_ Person. Details. This narrows the set of properties within the Person. Details class to those relevant in describing a subscriber within an employee benefits program, such as health or life insurance. Among the many properties within this sub-class would be “Tobacco User. Indicator” — essentially a Boolean value to capture information about tobacco use, which may be required for insurance program underwriting.
- Screening Subject_ Person. Details. This is the set of Person. Details properties relevant to describing someone who is the subject of employment screening, such as a pre-hire criminal record search. This restricted set of details does not include the above-referenced “Tobacco User. Indicator,” but does include a wide variety of other properties. For example, based on source-agency or court requirements, Screening Subject_ Person. Details includes an “Identifying Marks. Code” to classify visible features such as “tattoos”.
- Assessment Subject_ Person. Details This is a set of properties relevant in conducting employment-related testing or assessments. This sub-class for an assessment subject would include neither of the above-reference properties (Tobacco User. Indicator nor Identifying Marks. Code), but would share many other demographic properties with those other sub-classes, such as “Gender Code,” “Race Code,” etc. Such demographics typically are collected by test publishers to statistically validate that tests are predictive and do not have a disparate, discriminatory impact.
The three examples above are just a small glimpse of how the core components approach can help HR-XML improve consistency across its specifications without forcing an unwieldy, monolithic, one-size-fits all “person model” across diverse HR sub-domains. This post just scratches the surface. I’ll revisit the above approaches and other examples in later posts.