Context Methodology (CM) SC Report

Eve Maler

1 November 2001 [corrected in accordance with TC instructions]

This subcommittee has the following members:

Also attending as an observer on Wednesday afternoon and Thursday morning were Dale McKay, Doug Bunting, and Bob Glushko.


"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:

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.

Dale McKay has asked to be added to the TT SC as a voting member, if the TC agrees.[Accepted by the TC.]

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

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.

Context driver selection by means of drop-downs

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.

Flowchart with generic XSD and context stylesheet as input and contextualized XSD as output

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.

Pro Con
Option 1: additive TBD TBD
Option 2: subtractive TBD TBD
Option 3: additive then subtractive (what is this?) TBD TBD
Option 4: subtractive then additive (what is this?) TBD TBD

Some of our goals are:

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:

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.