PDME — IdentificationContext Considered Harmful

Problem:
1. Confused "context" with "scope"
The spec muddles the following two things together:

• The need to maintain multiple identifiers for a single entity in different contexts: this Widget is known as Navy Part X, and
  also as Company Part Y. This is a user-level, real-world, business concept.
• The need to qualify the identifiers of different entities based on their scopes: Document X is not the same entity as Part X,
  and Revision Z of Document X is not the same entity as Revision Z of Document Y. This is an implementation-level concept.
  Conceptually, the scoping of identifiers occurs within a context, but the spec requires us to create separate
  IdentificationContexts for every scope.
  A special case was made to allow Revisions to be implicitly scoped by their Master (Section 2.3.3.6, just above Implementation
  Issues). This is even worse because it violates the model of identification. An identifier is supposed to uniquely specify an
  entity within a context. If a Revision cannot be unambiguously retrieved using only a context and an identifier, then Revision
  should not inherit from Identifiable.
  If Revisions are identifiable, then their identifications probably consist of a revision number qualified by a path to the
  Master or by some other information that is sufficient to identify the scope. That is not to say that a user interface would
  force the user to specify anything more than the revision number once the scope of that session has been established. This is
  similar to the usage of relative path names in a file system. But in the current spec, a Revision is like some weird, special
  kind of file that exists within its directory if you go there first but cannot ever be accessed using a fully-qualified path.
  Consider the ramifications for application programmers.
  2. High overhead
  A consequence of muddling scope with context is the proliferation of IdentificationContexts. A large number of these must be
  propagated into the Bill of Materials and retrieved and managed by every client program, no matter what the application. This
  creates special problems for query and traversal convenience functions because there is no convenient way to specify all of the
  needed IdentificationContexts.
  Alternately, in the case of implicit scoping, clients are unable to retrieve certain entities based on their identifications
  alone and must instead navigate from entities whose identifications are unambiguous. The client is forced to manage additional
  information and perform extra operations because the PDM does not maintain the uniqueness of identifiers. Clients should not be
  required to navigate to something that is Identifiable; they should be able to do a simple find-by-ID if an ID is what they've
  got.
  3. Interoperable client not feasible
  A client cannot rely on find_id_context to locate a usable IdentificationContext without special knowledge about the
  implementation because both the existence of a default context and the set of kinds that have associated IdentificationContexts
  are implementation-dependent. Instead, an interoperable client must use find_id_contexts to retrieve a list of candidate
  IdentificationContexts for each interface type and then select among the candidates. The client is trying assemble the
  collection of IdentificationContexts that would correspond to a single context if scope and context were not intermingled. But
  since they are, there is no interoperable way to determine which set of IdentificationContexts is appropriate.
  If the client should luck into an appropriate set of IdentificationContexts, it still must somehow discover and conform to the
  implementation-dependent rules for the properties to pass to generate_id. There does not seem to be any interoperable way to do
  this either.
  4. Implementation details are exposed
  The vendor's decision to use a single name space for all PDM objects or to use separate name spaces for every class of objects
  internal to the PDM is an implementation detail that need not be exposed and should not be exposed.
  Under the current spec, clients have the unenviable job of discovering and conforming to the internal name space structure of
  the PDM. They do not really benefit from the standardization of the interface because the behavior is still different for each
  implementation. Instead, the implementation details of identifications should be factored out of the standard interface.

Proposed changes:

1. Replace the first paragraph of Section 2.3.3.5 with the following: "The IdentificationContext object represents the business
context in which object identifications apply and the identification formats and rules that apply in that context. For example,
an identification context may define Navy part numbers and generate identifications conforming to the formatting and rules that
the Navy and the PDM require. Different contexts can be defined for different government agencies, vendors, or even internal
divisions."
2. Replace the first line of IDL with the following:
typedef string IdentificationContextName;
3. Add the operation CosPropertyService::PropertySet IdentificationContext::get_properties().
4. Delete the operation IdentificationContextFactory::find_id_contexts.
5. Delete all text between the IDL (starting with "Implementations...") and find.
6. Add the following description of get_properties(): "Returns a PropertySet indicating the names of the properties that are
required to generate a valid identifier in the current context. Default values may be supplied for some or all of the
properties. The client should fill in the values of the properties and then pass the filled-in PropertySet to generate_id.
7. Append the following text to the description of find_id_context: "The the_context_name parameter specifies the
business-related name. If the implementation supports a default identification context or only one identification context, the
default name is represented by the empty string (that is, a string of length 0)."
8. In Factory operations, delete the operation find_id_contexts.
9. In Section 2.3.3.6 Design, insert the following text as a new first paragraph: "A context represents a user-level,
real-world, business entity. It is entirely separate from any name space hierarchy and/or nomenclature rules that may exist
internal to the PDM implementation. Contrariwise, an IdentifierSeq is specifically intended to encapsulate the
implementation-dependent aspects of identification and may be used in whatever manner is most convenient to the implementor. An
arbitrary number of internal name spaces may be navigated using arbitrarily detailed IdentifierSeqs."
Append the following text at the end of what is currently the first paragraph: "...in some way. However, specific
interpretations of the content of an IdentifierSeq or identifier string are not within the scope of this standard. For maximum
interoperability, a PDM client should treat the IdentifierSeq as an illegible database key and the identifier string as
derivative text intended for presentation purposes only."
10. Delete Figure 2-1 and the paragraph that refers to it.
11. Retain Figure 2-2 and the paragraph that refers to it.
12. Delete Figure 2-3 and the remaining two paragraphs leading up to Implementation Issues.
13. In Implementation Issues, insert the following text as a new paragraph between the current first and second paragraphs:
"Customizability is also an important product differentiator. Internally, an implementation might support separate name spaces
for each descendant of Identifiable. A customer's part numbering system may be different from their document numbering system,
and their ECO numbering system will likely be different from those of parts and documents. These are trivially mapped to a
single name space per context by using the first component of the IdentifierSeq to select the name space, with the remaining
components conforming to the customer-dependent rules for that name space. This enables interoperable clients to achieve a
useful level of functionality treating the IdentifierSeq as an illegible database key while customized clients can interpret the
contents of the IdentifierSeq according to the needs of each customer."