Report to the UBL TC Naming and Design Rules Subcommittee Eve Maler NDR SC chair 22 January

What does the NDR SC do? Charter: “Recommend to the TC rules and guidelines for normative-form schema design, instance design, and markup naming, and write and maintain documentation of these rules and guidelines” The LC SC needs our recommendations right away; we hope to work closely with them at this F2F to get feedback I’m speaking under the SC’s control today

Current NDR SC members Bill Burcham Doug Bunting Dave Carlson Mavis Cournane Mark Crawford (editor, vice-chair) John Dumay Matt Gertner Arofan Gregory Eduardo Gutentag Eve Maler (chair) Dale McKay Joe Moeller Sue Probert Ron Schuldt Gunther Stuhec Mike Rawlins (thanks to all these folks for their hard work!)

How our work is organized NDR document holds all our recommendations SC members champion issues by writing position papers Only decided issues are incorporated into the NDR document –Not too many yet! –First two critical areas are nearly cooked –Our goal is to make rapid decisions on many of them this week

NDR document status An outline and initial non-normative text have been developed based on other similar documents SC has done one review pass for organization and clarity In NDR document draft 04, note:NDR document draft 04 –Design principles –Informative vs. normative material –Links to position papers –Glossary

Champions assigned (there will be more!) A-priority (we think): Schema language (Eve) [done] Legal issues (Dale) [done] Tag structure (Mark) “Modnamver” (Bill) Use cases (Dave) Others: Design principles (Mark) Customization (Arofan) [now owned by CM SC] Elements vs. attribs (Gunther) Doc size/performance (Gunther) Code lists (Mike) Local vs. global elements (Dave) UBL & CC relationship (Mark) TPA (Doug)

First two recommendations Schema language: –Our source format for schema files will be W3C XML Schema –Other formats may be generated from this Legal issues: –We sought advice on whether default values are a legal problem (as they’re absent from the instance but still part of the “data”) –Advice we received: “implied terms” have been acceptable for a long time

Tag structure progress “High structuring” of markup names Abbreviate names in this pattern: –Truncate object class prefix when subelement can be used with several object classes –Make such subelements local (not reusable, except as part of the complex type that defines it) –Always use “Details” suffix for aggregates (or “Document” for top-level elements) –Use judgment for subelements like AddressNumber that would be “un-anchored” without an object class Not sure yet about additional issues, such as usage of UDEF identifiers on elements

Tag structure example Elements containing “city” information might be reusable in many locations: airport city, rental car drop-off city, home address, etc. A CityName element would be defined in a complex type that gets used (directly or in derived form) to define all those “object-class-providing” parent elements The entire semantic for an instance of the element could be described with a simple XPath

Modnamver progress: nam One core namespace One namespace per root schema –Where a root schema defines all global types for one functional area Possibility of intermediate namespaces (and thus roots) as we go along –Likely for loading/performance reasons Not sure if namespace names will be URNs UBL extensions made by others must define their own namespaces –Which hopefully are keyed to contexts

Modnamver progress: mod Encourage creation of new instance roots (individual document types) even for slightly different document forms Root schema for instance root may include several schema modules, and will import core root schema –If intermediate levels get added, more roots will be imported at the various levels –How to handle “borrowing” across functional areas? Core root schema will probably have an artificial root element –For developer convenience

Module structure

Sample modules

Modnamver progress: ver Versions are associated with namespaces, not with individual modules We are considering a Major.Minor version number structure –Based on backwards compatibility of the change Not sure how to encode the versions yet –Attribute on root element? In namespace URI? As part of the context methodology? Not sure of relationship between core and functional namespace versions yet

What we hope to accomplish this week Prioritize position papers, identify issues, identify and track dependencies between them, and then develop recommendations Work with the CM SC and LC SC to determine priorities and get feedback With a better understanding of interdependent issues, we can be more effective in our weekly meetings

Agenda request Possible to meet in joint session with the CM SC and LC SC? Need to try out tag structure ideas Need to make sure we all understand each other Need to get a sense of priorities on additional NDR position papers

Thank you Eve Maler NDR SC chair 22 January