Context Methodology (CM) SC Report

Charter

"Develop a methodology and tools for applying context to the core library of generic business information entities (BIEs) in order to produce contextualized BIEs, and develop initial machine-readable descriptions of context rules, in the service of helping the Library Content SC do its work."

Some possible work products out of this group:

• A BIE transformation language that takes a schema module and a list of context driver values as input
• A language that encodes context driver values

This group will likely need to exist for the duration of the TC, since it has direct relevance to both Phase 1 and Phase 2.

We would like to propose a new SC with the following charter: Work on improvement and further development of the context drivers and their values. [Accepted by the TC, with an initial voting member list and with Sue Probert as chair.]

SC Logistics

Matt Gertner has tentatively offered to chair this SC, if the TC agrees. [Accepted by the TC.] Eduardo Gutentag has agreed to edit the CM report. Arofan Gregory has agreed to be liaison between this SC and the Library Content SC.

We agreed to communicate primarily by email for now, and to act in a consultative role to the Library Content SC.

ACTION: Matt to start a thread on the mailing list by the end of next week to collect issues.

Analysis Inputs

• ebXML specification for the application of XML based assembly and context rules: V1.04 covered schema-related transformation. Later versions removed this design focus.

Understanding of the Problem for UBL

Users of UBL need to have a very concrete way of specifying context and having it result in a schema they can use. This might be done by picking from among a small set of options offered by an influential trading partner, or filling in a web form to get a generated result, or whatever. Following is how a web form might look to a SME looking for an appropriate format for a particular document type.

In a sense, core components are just BIEs that have the defaulted context driver values. If we start with schema modules that encode these generic BIEs, then a transformation process can be applied to them that turns them into contextualized BIEs.

The XML Schema appinfo field could be used to hold the context driver values once the contextualized XSD is generated.

(There was more discussion that wasn't entirely captured.)

Customization Discussion

Here are some of the options for customization that needs to be done in the contextualization process.

Some of our goals are:

• We want to collect data about the customizations being made by users and communities of users, so that future versions of the core can respond to their needs.
• We want to allow customizations to be created "organically" (that is, we don't want to stand in the way of true user needs), but we want to provide a methodology and tools for creating customizations that is so attractive that other methods are not used often.
• We want to allow communities of users to create their own "standard customizations". Assuming that our methodology and tools are robust enough, this could be viewed as allowing them to persist sets of contextualized schemas derived from UBL.
• We want to allow contextualized schemas to be further customized by the same mechanism that produced them.
• We want to avoid "tag abuse" problems that arise from requiring unnecessary elements.

ebXML History

Core components are the semantic models that underlie all e-business. A business information entity is a core component that has had context applied to it. The formalization of context resulted in a set of classifications that could theoretically uniquely describe a business situation:

• Business process: an extensible hierarchy
• Business process role: the business process, qualified by sender and receiver
• Industry classification: UN/SPSC was recommended; it is hierarchical
• Product classification: UN/SPSC and others were recommended
• Official constraints: punted; supposed to reference a body of law (by its nature hierarchical, but not for these purposes)
• Geopolitical: based on ISO 3166, though it misses groupings of countries
• Supporting role: a functional role code; not hierarchical, just a flat code list
• Systems capabilities: can register your constraints with a repository

Multiple values are allowed for each. Defaults are provided. The "distance" between any two situations could be measured in an n-dimensional way. Nominally, these classifications are orthogonal to each other.

It was imagined that a semantic model would be assemled in a static fashion, and then refined by reference to the context classification values.

At the semantics level: CC->assembly->BIE. Then BIE gets bound to a syntax. However, ebXML defined manipulation syntaxes for CCs and assembled results too.