Added by gunther.stuhec, last edited by gunther.stuhec on Dec 13, 2007

Labels

 
(None)
Number Category Name Description Comment 1.) Miley Watts 2.) SAP  
1 CCTS UCM shall define context for CCTS UCM shall define context concepts as they apply to CCTS. Coates - based on submission of Joe Zhou.  
2 CCTS UCM shall define CCTS context methodology UCM shall define a methodology for applying contextual refinements (customizations, extensions, restrictions, etc.) to core components and business information entities. Coates - based on submission of Joe Zhou.  
4 Model UCM shall include a meta-model UCM shall include a meta-model showing the context concepts. May include appropriate associations, properties, enumerations, and cardinalities. This is to reduce ambiguity and promote common understanding of the context model.  
7 Migration UCM shall not preclude migration of CCTS contexts UCM shall not preclude migration of existing CCTS contexts to UCM. Coates - based on submission of Joe Zhou.  
8 Migration UCM shall specify migration guidelines UCM shall specify migration guidelines from the previous CCTS context driver approach (section 6.2 of CCTS 2.01). Coates - based on submission of Joe Zhou.  
12 Model UCM shall be able to classify contexts UCM shall be able to organize or classify contexts into categories. E.g. geopolitical region, industry. Could be done through taxonomy, ontology, folksonomy (tagging), or other means.
This is to (for example) promote and facilitate reuse of components, and to enable context-driven message assembly.
 
14 Processing UCM shall provide a design-time context mechanism UCM shall provide a mechanism for specifying and applying contextual refinements to supported artifacts at design-time. Coates - based on submission of Joe Zhou.  
15 Processing UCM shall provide a run-time context mechanism UCM shall provide an embeddable format for identifying/expressing business context. The format shall be usable for annotating messages with business context information. This could be used to facilitate and/or simplify validation at run time.  
Tony - not defined as yet, but requires that you can uniquely identify context nodes. This can be done by UUID, URI, and by name (or a path including ancestor names, as many as required to produce a unique identifier).
 
Gunther - The submission has a place holder for it. It will be handed in later.
 
16 Model UCM shall define an extension and maintenance method for the context model UCM shall define an extension and maintenance method for the context model.    
Tony - the model is extended by adding new contexts (including category or sub-category contexts) and/or new association types. Maintenance is not yet considered.
Gunther - The sumission describes it partially. It must be refined.  
19 Model UCM shall allow full lifecycle management of the context model UCM shall allow full lifecycle management of the context model. For example, determination of dependencies, facilitation of model merges.
Coates - based on submission of Joe Zhou.
 
Tony - supports specification and publication of future-dated changes, but not yet other parts of lifecycle management.

Gunther - The submission describes it partially. It must be refined.
 
21 Dependencies UCM shall minimize dependencies UCM shall structure the methodology and specifications to minimize dependencies on specific implementation technologies and other specifications. Coates - based on submission of Joe Zhou.  
22 Integration UCM shall be cohesive with CCTS, CCMA, and BPSS UCM shall have a cohesive approach with CCTS, CCMA, and BPSS, but should be as loosely coupled as possible. Coates - based on submission of Joe Zhou.
Gunther - The starting point of this submission is CCTS, but it can be also used for other artefacts such as BPSS.
 
24 Documentation UCM shall specify methodology but not implementation UCM shall define a context methodology, but shall not define how that methodology should be implemented.    
27 Documentation UCM context mechanism design must follow a well known source of definition for "context" The UCM context mechanism design must follow a well known source of definition for "context", and this definition must be published within the specification(s). UCM or UN/CEFACT can be the source of the definition, as appropriate.    
31 Internationalisation UCM should prescribe language for categories/constraints UCM shall prescribe in which language categories/constraints should be defined. This should be done in conjunction with the EBAWG to align with what is done in other UN/CEFACT specifications. In particular, the approach should be aligned with the approach of CCTS.  
32 Model UCM shall support "broader/narrower" contexts UCM should be able to define which contexts have a "broader" or "narrower" relationship with other contexts.  
Partially - but can be extended
 
33 Scope Implementation verification shall include serialisation Implementation verification shall include at least one serialisation syntax for the UCM context model.    
Tony - not yet considered.

It is based on XMLNDR for CCTS
 
34 Model UCM shall not limit the number of context categories UCM shall not limit the number of possible or allowed context categories (or whatever is the equivalent concept in the UCM context model).    
35 Code Lists UCM shall define how code lists are used in the UCM context model UCM shall define how code list information is represented and used in the UCM context model.    
Tony - code lists can be represented by a category context, with sub-contexts for each code list entry. Sub-categories could be used to distinguish versions of code lists, with assocations added to navigate previous/next versions of code lists or code values.
 
36 Model UCM context model shall support multi-parent hierarchies UCM shall allow for multiple-parent context hierarchies. It may be worth considering how this context model might integrate with relevant external taxonomy/ontology models.group.  
37 Code Lists UCM shall support multiple code lists for context categories UCM shall support multiple possible code lists for each context category (or whatever is the equivalent concept in the UCM context model). UCM shall specify a mechanism for encoding the active choice(s) of code lists. URIs might be used to specify particular code lists.  
Tony - see #35
 
38 Model UCM shall be able to represent all aspects which make up a particular specific business context UCM shall include a kind of logic that allows the explicit setting of sets of business context categories and valid business context values in order to formally describe the context of a specific artifact' s context. The context logic must allow for specifying exceptions. Example: a specific entity is valid in BP "Purchase Ordering" for all countries without "Germany". The same entity is also valid in BP "Invoicing" if the country is "Germany".
Agreement that need for mathematical/ formal logic approach.
 
39 Processing UCM shall support selection of artefacts based on business context UCM shall define a context processing model which supports business process role (context role) specific selection and customisation of relevant artefacts, taking into account the specific context aspects of the roles of each participant in a business process. The context processing behavior may consider the qualifiers of ISO 11179 based artifact names.  
Tony - currently only takes into account broader/narrower/same-as associations.
 
40 Identification UCM shall provide a mechanism for creating namespace URIs based on contexts UCM shall define a method for creating unique namespace URIs based on particular business contexts. This should be done in conjunction with ATG. These namespace URIs can be used for contextually identifying individual sections of XML messages.  
Tony - not done yet, but see #15.

Gunther - It will be the next step of this submission.