DEPL — Need global unique identifier scheme compliant with MOF 2.0 standard

Problem:
"UUID names" need to be defined as hierarchical in nature to create global uniqueness, while still supporting a simple local uniqueness. This should be accomplished using the URI approach defined by W3C as referenced in MOF 2.0. This approach provides an unambiguous solution that is scalable.

The following MOF 2.0 excerpt references the W3C URI uniqueness as a solution.

P1_01_MOF-Architecture.fm ad/2002-12-10 1-18
7. MOF 2.0 models the concept of identity. The lack of this capability in MOF, UML, CWM etc., made interoperability of metadata difficult to implement. The submitters understand that modeling identity is not easy, but we plan to show its usefulness in a simple domain - identity of metadata first. A key design goal is to make it easy to map this model of identity to W3C identity and referencing mechanisms such as the URI.

The following excerpt from the W3C URI spec introduces the concept of an absolute URI. Using this absolute URI as a tentative solution would resolve the current naming and uniqueness concerns. An objects globally unique name would consist of its local name space name prefixed with the names of all objects in its containment hierarchy.

Berners-Lee, et. al. Standards Track [Page 10]
RFC 2396 URI Generic Syntax August 1998
3. URI Syntactic Components

The URI syntax is dependent upon the scheme. In general, absolute
URI are written as follows:

<scheme>:<scheme-specific-part>

An absolute URI contains the name of the scheme being used (<scheme>)
followed by a colon (":") and then a string (the <scheme-specific-
part>) whose interpretation depends on the scheme.

The URI syntax does not require that the scheme-specific-part have
any general structure or set of semantics which is common among all
URI. However, a subset of URI do share a common syntax for
representing hierarchical relationships within the namespace. This
"generic URI" syntax consists of a sequence of four main components:

<scheme>://<authority><path>?<query>

each of which, except <scheme>, may be absent from a particular URI.
For example, some URI schemes do not allow an <authority> component,
and others do not use a <query> component.

absoluteURI = scheme ":" ( hier_part | opaque_part )

URI that are hierarchical in nature use the slash "/" character for
separating hierarchical components. For some file systems, a "/"
character (used to denote the hierarchical structure of a URI) is the
delimiter used to construct a file name hierarchy, and thus the URI
path will look similar to a file pathname. This does NOT imply that
the resource is a file or that the URI maps to an actual filesystem
pathname.

hier_part = ( net_path | abs_path ) [ "?" query ]

net_path = "//" authority [ abs_path ]

abs_path = "/" path_segments

URI that do not make use of the slash "/" character for separating
hierarchical components are considered opaque by the generic URI
parser.

opaque_part = uric_no_slash *uric

uric_no_slash = unreserved | escaped | ";" | "?" | ":" | "@" |
"&" | "=" | "+" | "$" | ","

We use the term <path> to refer to both the <abs_path> and
<opaque_part> constructs, since they are mutually exclusive for any
given URI and can be parsed as a single component.

Proposed resolution:
Require the use of unique component identifiers, these identifiers cannot be optional, duplicate, or blank/empty. All objects requiring identity management, or providing containment must have unique identifiers constructed using URI format and character content guidelines.

NOTE: there could be both a "relative" local unique identifier, and a global unique identifier (absolute). All objects need the local unique, but not all objects need the absolute global identifier. This point requires further discussion.

Use all unique component identifiers involved in an individual components containment hierarchy to produce a globally unique identifier for it. The W3C URI specification provided above states that this approach using identifiers with separator characters can be used for resources that are not related to file systems. These identifiers are intended to be global identifiers, and not necessarily paths to objects. It could be assumed that a well defined name would provide object locator information if properly used.

The FTF team should feel free to define exactly this global identifier constructed using unique namespace identifiers and "separator characters". The scheme should be described, but left available for implementers to define.