>
>
><Quote4>
>[3] Not present in my implementation but I see the need for it now.
>For instance, to store localized enumeration/regexps. BIEs have
>Contexts (Classifications) that could define the region where they
>should be used.. Same CC, different BIE for different region,
>different DataType, but still same CCT.
></Quote4>
>
>Joe: Glad you brought this up - the issue of whether or not Data Types should
>be stored as Registered Objects or be represented as metadata attributes
>for Registered Objects will be a big one for us.
>
mm1: I would ask the OAG-CC group about their work in this arena as they
have been modeling the XML schema of their CC. See Garret Minakawa,
.
>
><Quote5>
>And what about Contexts? Do they need a pattern too? I've used RIM's
>Classification mechanism for Contexts so that each Context Category
>has it's own ClassificationScheme.
></Quote5>
>
mm1: Note, there has been discussion in the CCSD team that a controlled
vocabulary may be required when it come to context. See this
***draft*** extract from the primer:
<<4.5.1Use of Context in Core Component Normalization
Qualifiers that are used in the naming of Business Information Entities
associate a context specific semantic with the Core Component. These
qualifiers make up a controlled vocabulary that can have unique semantic
within a specific context. For instance, "reserved" used as a qualifier
has an order process context semantic, as well as a travel industry
context semantic. Rigor in the construction of the controlled
vocabularies for qualifiers is as important as rigor in the construction
of the controlled vocabulary for core components. A qualifier should be
used consistently across the library of core components. The qualifier
context category, semantic, and control vocabulary source should be
noted. >>
Thanks.
Monica
