Paul Kiel Chief Architect Localization Design Approaches Heidelberg

Paul Kiel Chief Architect Localization Design Approaches Heidelberg, July 2003

Localization Topics § Localization – what do we mean? § How to localize - at design time § How to localize - after design time § Subsetting – using only the parts you need § Adding requirements – living life in an optional world § Passing regional taxonomies

Localization – addition § Adding data blocks to the standard, based on region or jurisdiction § Assumptions: l l 1) an international “base” standard 2) Can be for region (i. e. jurisdiction) or my implementation

Localization – subtraction (a. k. a. subsetting) § § Omitting data blocks that are not applicable in a given region or jurisdiction Assumptions: l l 1) an international “base” standard 2) Can be for region (i. e. jurisdiction) or my implementation

Localization Topics § Localization – what do we mean? § How to localize - at design time § How to localize - after design time § Subsetting – using only the parts you need § Adding requirements – living life in an optional world § Passing regional taxonomies

Adding data blocks § Q: How do we design a schema to allow the addition of regional data (using simple techniques)? § A: Using a “union” or a “choice”. § Some examples ….

Payroll example – a union

Payroll example - a union § Let’s see the code ….

Enrollment example - a choice

Enrollment example - a choice § Let’s see the code ….

Localization § Benefits of this design: 1. Simple 2. Future proof 3. TPA friendly

Localization Topics § Localization – what do we mean? § How to localize - at design time § How to localize - after design time § Subsetting – using only the parts you need § Adding requirements – living life in an optional world § Passing regional taxonomies

Adding data blocks § Q: How do we add regional data after the standard is complete? § A: User. Area extension. § An example ….

Localization Topics § Localization – what do we mean? § How to localize - at design time § How to localize - after design time § Subsetting – using only the parts you need § Adding requirements – living life in an optional world § Passing regional taxonomies

Subtracting data blocks (a. k. a. subsetting) § Reasons for subsetting: l l l Reducing bloat Regulation (i. e. collecting age, gender, race data) Applicability of data to region (tighten up the spec)

Subsetting – adding additional constraints § 1) Use xsd: restriction l l § Considered broken in XML Schema Code is duplicated for the most part – little code savings 2) Edit the schema l Cannot be auto-generated • l l § (ok you can … but you don’t want to!) High potential for error Keeping in sync with standard requires vigilance 3) Add additional constraints or requirements in a second step l Requires two-step validation

Localization Topics § Localization – what do we mean? § How to localize - at design time § How to localize - after design time § Subsetting – using only the parts you need § Adding requirements – living life in an optional world § Passing regional taxonomies

Editing the schema for local needs § Remove optional elements not needed l § Replace string elements with enumerated lists in my implementation l § For regional data or TPA-specific local data Add database field lengths to data elements l For TPA-specific local data

Editing the schema for local needs – an example Q: How do I communicate my database field lengths for HR-XML elements like <Family. Name> or <Id. Value> to my business partner? A 1: Edit the schema A 2: Leave schemas alone and add second step

Editing the schema Change this: <Family. Name><!– any length string --></Family. Name> <element name="Family. Name" type="string"/> To this: <Family. Name><!– 15 characters or less --></Family. Name> <element name="Family. Name"> <simple. Type> <restriction base="string"> <max. Length value="15"/> </restriction> </simple. Type> </element>

Editing the schema for local data Problem: What about Ids which may have different values in different contexts? § Changes cannot be globally done § Requires extensive editing of the original schema to “undo” the reusable modularization we benefit from at design time

Editing the schema for local data Plus: easy to understand Plus: one-stage validation Minus: requires editing of the original schema (perhaps extensive) Minus: maintenance requires highly duplicative replicas of schemas Minus: Cannot be auto-generated • (ok you can … but you don’t want to!) Minus: High potential for error Minus: Keeping in sync with standard requires vigilance

Adding constraints in a second step <Person. Name> <Family. Name><!– 15 characters or less --></Family. Name> </Person. Name> First we create an XML file which lists constraints: <rule context="Person. Name"> <assert test="string-length(Family. Name) < 15"> Error message: Family. Name must not exceed 15</assert> </rule> Then validate the instance using any XSLT processor.

Adding constraints in a second step Even better – unique contexts: <rule context=“Person/Government. Id"> <assert test="string-length(Id. Value) < 10"> Error message: Id. Value must not exceed 10</assert> </rule> <rule context=“Company/Benefit. Plan. Id"> <assert test="string-length(Id. Value) < 6"> Error message: Id. Value must not exceed 6</assert> </rule>

Adding constraints in a second step

Adding constraints in a second step Let’s see an example ….

Adding constraints in a second step Plus: no editing of schema (nor duplicative replicas) Plus: addition of new constraints is easy (and easily communicated) for regional or TPA-specific local data Minus: requires two-stage validation Minus: not as intuitive to implement as editing of schemas

Localization Topics § Localization – what do we mean? § How to localize - at design time § How to localize - after design time § Subsetting – using only the parts you need § Adding requirements – living life in an optional world § Passing regional taxonomies

Passing Taxonomies § Q: How can I communicate my taxonomies to my business partner?

Passing Taxonomies – Job classification example Why sure ! May I have your job classes? <Code. List> <Code. A>123</Code. A> <Code. B>456</Code. B> …. . </Code. List>

Passing Taxonomies – Job classification example Posting, please. Thank you ! <Job. Posting> <Class. Id>123</Class. Id> … </Job. Posting>

Passing Taxonomies – SIDES Staffing. Action action types enums May I have your Staffing Action types? No problem ! <Action. List> <Action>Request. Int</Action> <Action>Reject. Int</Action> …. . </Action. List>

Passing Taxonomies – SIDES Staffing. Action action types enums Thank you ! <Staffing. Action> … <Action. Type>Request. Int </Action. Type> … </Staffing. Action> Staffing Action, please.

Passing Taxonomies – the problem All these taxonomies ! Most cumbersome ! <Action. List> …. . <Action>Request. Int</Action> <Action>Reject. Int</Action> …. . </Action. List> <Code. A>123</Code. A> <Code. B>456</Code. B> …. . </Code. List>

Questions for you § What are my localization needs? § Were my needs addressed in the presentation? § Will these localization techniques work for me?

www. hr-xml. org Questions? paul@hr-xml. org