UBL Context Methodology Subcommittee

Initial Steps

• List open questions (guided by ebXML work)
• Seek consensus on the appropriate answers

Questions and Conclusions

Question #1: Should we use ebXML deliverables as the basis for our work?

• ebXML context effort had many of the same goals as our subcommittee
• "Document Assembly and Context Rules v1.04" specifies a framework for applying context rules that could serve as the basis for continuing UBL work
• Conclusion: ebXML work is incomplete and flawed, but has valuable insights and should be seen as a starting point for the CM SC.

Question #2: Should we use XSD derivation?

• XSD has built-in derivation mechanisms for extending base types
• Explicit use of these mechanisms when creating new types using context rules could help processing applications
• Many open questions, including how applications will process XML using schema
• Conclusion: We will try to remain schema-independent for now, and tackle this question later

Question #3: Support for subtractive refinement?

• XSD has derivations features for extensions (adding stuff) and refinement (removing stuff)
• Support for refinement would enable use of more comprehensive core components, enhancing interoperability
• Conclusion: We should anticipate use of both additive extension and subtractive refinement, since it is likely that both will be needed

Question #4: Use of XSLT to express context rules?

• Context rules can be expressed using an ad hoc language or a standard transformation language like XSLT
• Use of XSLT would enable support for standard tools
• Conclusion: Since XSLT does not appear to have all the features needed for the context rule language, we will use an ad hoc language

Question #5: Hierarchical context drivers?

• Some context drivers are hierarchical
  • France is a subregion of Europe
  • Software is a subindustry of information technology
• Some context rules might need to apply automatically to subvalues, while some might not
• Conclusion: Some valuable suggestions have been made about how to express this distinction in context rules, but discussion continues

Question #6: Do we need assembly rules?

• The ebXML rule included assembly rules to put together components into documents, as well as context rules
• Since UBL explicitly uses XML and XML Schema, schemas can be used directly to assemble components into documents
• Conclusion: no special assembly rules are needed

Question #7: Should names be based on XSD?

• The ebXML work defined a context rule language that was distinct from XSD
• If we choose to use XSD to express all components, we could harmonize the context rule language to use XSD names
• Conclusion: To avoid needless dependencies, we will continue to choose the best names without relying on XSD

Question #8: What aspects of the ebXML document are "broken"

• The ebXML document is a good starting point
• But, there is general consensus that much work is still to be done
• Conclusion: We don’t know enough to identify all problems, so we will create use cases and test them iteratively as the next step

Dependencies

• Work on extension methodology, recommending how derived types should be designed
  • Preliminary document created by Arofan
  • Work continues as part of CM SC (moved from NDR SC)
• Use Cases
  • Not enough business expertise in the CM SC
  • We rely on other SCs (Core Library, etc.) and outside groups (EWG, etc.)
• Components
  • Naming depends on work of NDR SC
  • Actual components dependent on Core Library SC

Plea for Use Cases

• Use Cases are a necessary next step in order for our work to continue
• We are not capable of creating these Use Cases ourselves
• Requests for Use Cases have met with polite responses, but no concrete results
• Detailed Use Case requirements document is now available

Next Steps

• Gathering of Use Cases
• Testing of Uses Cases against ebXML document
• Drafting of first UBL Context Methodology Specification based on results of these tests
• Review and iterative revision of this specification