1. Technical Steering Committee La Jolla, January 2003 Paul Kiel, HR-XML

2. Topics §Certification §Validation web service §Framework binding §“HR-XML-2_0” Architecture (including localization) §Constraint problems §Future Issues

3. Validation Web Service § Web service validation testbed l http://testbed.hr-xml.org l To be updated after Feb release of library l http get, soap (i.e. XMLSpy’s soap)

4. Framework Binding Proof of Concept §HR-XML payloads used in various messaging frameworks l Not guidance, but annotated examples §Thus far: Provisional Envelope SOAP Headers Web service l ebXML - Send me your code! (paul@hr-xml.org) §OAGIS BODs l Send me your code! (paul@hr-xml.org)

5. HR-XML 2_0 Architecture §Described in SchemaDesignGuidelines-2_0.doc l On CD l http://schemas.hr-xml.org/xc/canon/TSC/ SchemaDesignGuidelines-2_0.doc §Summary: l Don’t fix what isn’t broken l New Namespaces Release structure l Constraints Verbs and Contextual schemas Database field lengths

6. Don’t fix what isn’t broken §Simple, reusable schema design §Small, discrete CPOs §Work group reusables (work group CPOs) §Naming conventions §Use of elements versus attributes §Extended enumerations §Best Practices aware (www.xfront.com)

7. §Globally scoped components § Locally Scoped components Naming and Scoping

9. New Release Structure  HR-XML-2_0 Library  Previously had versioned each spec type  Reusable design of specs leads to integrated library  For all schemas in the HR-XML Library, including CPOs.  Versioning moved to “version” attribute of schema element.

10. New Namespace  http://ns.hr-xml.org  For all schemas in the HR-XML Library, including CPOs.

11. Localization

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

13. Adding Constraints §Verbs l CreateTimeCard = DeleteTimeCard l How do I communicate what is required in each context? §Tighten up specs for my needs §Field lengths l How do I communicate my database field lengths for HR-XML elements like to my business partner?

14. Constraints headache # 1: Verbs §Q: What do we do with our HR-XML objects? §A: We _____ them. Create Update Delete Remove … §Payroll transaction codes: l Add, Audit, Change, Correction, Delete, Suspend, Terminate §Stock codes: l Create, Remove

15. Verbs: The consequences The result of verb-specific elements is that there will be more versions of our schemas that only differ in occurrences, not in content. Q: So what?

16. Verbs: The consequences A: Short Term – nothing. We can issue “contextual schemas”: l CreateTimeCard l UpdateTimeCard l DeleteTimeCard l … A: Long Term – well?

17. Verbs: The consequences The long term problem: more nouns x more verbs = more schema variations! (with no content changes, only occurrence changes) Can we manage this?

18. Verbs: Then and Now Then HR-XML Library master schemas (approx): §24 Nouns (non-CPO) §x 3 Verbs §= 72 Schemas §(plus 20 modules = 92 Schemas) Then HR-XML Library (with modules, CPOs) (approx) : §44 Nouns in all §x 3 Verbs §= Potential of 132 Schemas! 29 87 123 36 65 195 !

19. Constraints headache # 2: tightening up the spec Result of committee work – fewer required fields! Adding constraints allows a company to more accurately reflect business needs

20. Constraints headache # 3: field lengths Q: How do I communicate my database field lengths for HR-XML elements like or to my business partner? A1: Edit the schema (like “context schemas” in verbs issue) A2: Leave schemas alone and add second step constraints (XPath based)

21. A1: Edit the schema for each field length Change this: To this:

22. A1: Edit the schema for each field length 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 benefited from at design time

23. A1: Edit the schema for each field length Plus: one-stage validation Plus: easy to understand Minus: requires editing of the original schema (perhaps extensive) Minus: maintenance requires highly duplicative replicas of schemas

24. A2: XPath based constraints First we create an XML file which lists constraints: Error message: FamilyName must not exceed 15 Then validate the instance using any XSLT processor.

25. A2: XPath based constraints Even better – unique contexts: Error message: IdValue must not exceed 10 Error message: IdValue must not exceed 6

26. A2: XPath based constraints

27. Plus: no editing of schema (nor duplicative replicas) Plus: addition of new constraints is easy - and easily communicated Minus: requires two-stage validation Minus: not as intuitive to implement as context schemas

28. Future Issues § Big: l Documentation A more comprehensive approach l Constraints guidance (document first draft exists) §Little: l Versioning of schemas within library? l Enforce “Type” extension on named types l Enforce singular type names, plural unions? l Enforce no anonymous types?

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