Localization Design Approaches Paul Kiel Chief Architect Localization Design Approaches Heidelberg, July 2003 Welcome, introductions.

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 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: 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: 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 …. Look at BenefitDeductionCategoryType.xsd, USbenefit.xsd, and xml instance

Enrollment example - a choice

Enrollment example - a choice Let’s see the code …. Look at coveragetypes.xsd, UScoveragetypes.xsd, and xml instance.

Localization Benefits of this design: Simple Future proof 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: UserArea extension. An example …. Look at resume instance example (with resume MYCO.xsd doc)

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: 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 Considered broken in XML Schema Code is duplicated for the most part – little code savings 2) Edit the schema Cannot be auto-generated (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 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 For regional data or TPA-specific local data Replace string elements with enumerated lists in my implementation Add database field lengths to data elements 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 <FamilyName> or <IdValue> to my business partner? A1: Edit the schema A2: Leave schemas alone and add second step

Editing the schema Change this: <FamilyName><!– any length string --></FamilyName> <element name="FamilyName" type="string"/> To this: <FamilyName><!– 15 characters or less --></FamilyName> <element name="FamilyName"> <simpleType> <restriction base="string"> <maxLength value="15"/> </restriction> </simpleType> </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 <PersonName> <FamilyName><!– 15 characters or less --></FamilyName> </PersonName> First we create an XML file which lists constraints: <rule context="PersonName"> <assert test="string-length(FamilyName) < 15"> Error message: FamilyName 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/GovernmentId"> <assert test="string-length(IdValue) < 10"> Error message: IdValue must not exceed 10</assert> </rule> <rule context=“Company/BenefitPlanId"> <assert test="string-length(IdValue) < 6"> Error message: IdValue must not exceed 6</assert>

Adding constraints in a second step

Adding constraints in a second step Let’s see an example …. Show son of monkey tool for creating xslt. Then web service to validate an instance.

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? <CodeList> <CodeA>123</CodeA> <CodeB>456</CodeB> ….. </CodeList>

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

Passing Taxonomies – SIDES StaffingAction action types enums No problem ! May I have your Staffing Action types? <ActionList> <Action>RequestInt</Action> <Action>RejectInt</Action> ….. </ActionList>

Passing Taxonomies – SIDES StaffingAction action types enums Staffing Action, please. Thank you ! <StaffingAction> … <ActionType>RequestInt </ActionType> </StaffingAction>

Passing Taxonomies – the problem All these taxon-omies ! Most cumbersome ! <ActionList> ….. <Action>RequestInt</Action> <Action>RejectInt</Action> </ActionList> <CodeList> <CodeA>123</CodeA> <CodeB>456</CodeB> ….. </CodeList>

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