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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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 ….

8. Payroll example – a union

9. Payroll example - a union
Let’s see the code ….
Look at BenefitDeductionCategoryType.xsd, USbenefit.xsd, and xml instance

10. Enrollment example - a choice

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

12. Localization
Benefits of this design:
Simple
Future proof
TPA friendly

13. 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

14. 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)

15. 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

16. 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)

17. 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

18. 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

19. 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

20. 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

21. 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>

22. 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

23. 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

24. 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.

25. 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>

26. Adding constraints in a second step

27. 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.

28. 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

29. 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

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

31. Passing Taxonomies – Job classification example
Why sure !
May I have your job classes?
<CodeList>
<CodeA>123</CodeA>
<CodeB>456</CodeB>
…..
</CodeList>

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

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

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

35. 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>

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

37.
Questions?