1 / 29

HR-XML Technical Steering Committee Updates and Future Directions

Explore updates from the HR-XML Technical Steering Committee meeting in January 2003, including certification, web service validation, framework binding, and localization considerations. Learn about the new HR-XML-2_0 architecture, constraints, and how to tackle validation issues in web services.

marlenel
Download Presentation

HR-XML Technical Steering Committee Updates and Future Directions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 • http://testbed.hr-xml.org • To be updated after Feb release of library • http get, soap (i.e. XMLSpy’s soap)

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

  5. HR-XML 2_0 Architecture • Described in SchemaDesignGuidelines-2_0.doc • On CD • http://schemas.hr-xml.org/xc/canon/TSC/ SchemaDesignGuidelines-2_0.doc • Summary: • Don’t fix what isn’t broken • New • Namespaces • Release structure • 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. Naming and Scoping • Globally scoped components <ObjectTypeName/> • Locally Scoped components <Object> <Type> <Name/> </Type> </Object>

  8. 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. <xsd:schema targetNamespace="http://ns.hr-xml.org" xmlns="http://ns.hr-xml.org" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" version="2_0">

  10. New Namespace • http://ns.hr-xml.org • For all schemas in the HR-XML Library, including CPOs. <xsd:schema targetNamespace="http://ns.hr-xml.org" xmlns="http://ns.hr-xml.org" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" version="2_0">

  11. Localization

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

  13. Adding Constraints • Verbs • CreateTimeCard = DeleteTimeCard • How do I communicate what is required in each context? • Tighten up specs for my needs • Field lengths • How do I communicate my database field lengths for HR-XML elements like <FamilyName> 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: • Add, Audit, Change, Correction, Delete, Suspend, Terminate • Stock codes: • 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”: • CreateTimeCard • UpdateTimeCard • DeleteTimeCard • … 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) 29 87 123 36 Then HR-XML Library (with modules, CPOs) (approx): • 44 Nouns in all • x 3 Verbs • = Potential of 132 Schemas! 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 <FamilyName> or <IdValue> 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: <element name="FamilyName" type="string"/> To this: <element name="FamilyName"> <simpleType> <restriction base="string"> <maxLength value="15"/> </restriction> </simpleType> </element>

  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: <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. A2: XPath based constraints 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> </rule>

  26. A2: XPath based constraints

  27. A2: XPath based constraints 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: • Documentation • A more comprehensive approach • Constraints guidance (document first draft exists) • Little: • Versioning of schemas within library? • Enforce “Type” extension on named types • Enforce singular type names, plural unions? • Enforce no anonymous types?

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

More Related