DEPL — XMI should be used for schema generation

This is a new issue for the Deployment FTF:

Instead of introducing a new set of rules, the existing rules
for XMI 2.0 Schema Production should be used.

Proposed resolution:

In section 6.1, "Introduction", change the last paragraph to read,

The M1 mapping is realized using the UML Profile for CORBA, the
M2 mapping is realized using the XML Metadata Interchange (XMI)
Version 2 specification, chaper 2, "XML Schema Production."

In section 6.5, "PIM for CCM to PSM for CCM for XML Transformation",
change the first paragraph to read

This section defines transformation T3 (as described in the
introduction). It transforms the PIM for CCM into a PSM for CCM
for XML that can be used to generate a concrete XML schema using
the mapping rules described in chapter 2, "XML Schema Production"
of the XML Metadata Interchange (XMI) Version 2 specification.

Change the Generic Transformation Rules to read

Data model elements, annotated with the «Description» or
«enumeration» stereotype (or a stereotype that inherits from it),
are used to generate XML schema for persistent storage of metadata.

Management model elements, annotated with the «Manager» or
«Exception» stereotype, are not part of the PSM for CCM for XML,
they are mapped to IDL only.

All classes in the PSM for CCM for XML are annotated with the
"org.omg.xmi.contentType" tag set to the value "complex".

All attributes are annotated with the "org.omg.xmi.element"
tag set to "true".

All packages are annotated with the "org.omg.xmi.nsURI" tag
set to "http://www.omg.org/DnC" and the "org.omg.xmi.nsPrefix"
tag set to the value "DnC".

In the Special Transformation Rules section, in the description for
the Any type, delete the Note that reads "Investigate whether the Any
type that is part of XMI is sufficient."

In the Others subsection of the Special Transformation Rules, add the
following paragraph:

The location attribute of the ImplementationArtifactDescription
class and the idlFile attribute of the ComponentInterfaceDescription
class contain URIs pointing to a file. URIs that consist of a
relative path (using the rel_path branch in the URI BNF) are
interpreted relative to the directory that the current document
is in. URIs that consist of an absolute path (using the abs_path
branch in the URI BNF) are interpreted relative to the current
package.

Change the Transformation Exceptions and Extensions section to read

Metadata for a component package is usually spread out across several
XML files, which we call descriptors. Certain associations are expected
to be expressed by links within the same document, others are expected
to link across documents. XMI takes care of both patterns by way of
"proxies," which do not contain nested elements but a link attribute
(either "href" or "xlink:href") referencing the target element by URI.
A schema produced using the XMI rules for schema production allows
proxies to appear anywhere.

Composition associations in the model express that the class at the
composite end owns and contains the class at the part end. In an XML
file, the element that defines the class at the part end usually
directly contains the definition for the class at the composite
end. Since the default multiplicity on the near end of a composite
association is one to one, the contained item cannot be legally
contained in another element. It is possible to store it by itself
in a separate file, though.

For non-composite associations between classes with a common owner
(composite end of composition), the definition of the class at the
source end of the association must contain a proxy linking to the
element at the target end of the association. The definition of the
class at the source end cannot contain the definition of the element
at the target end, because it is owned by the common owner, and its
identity cannot be duplicated.

Non-composite associations between classes that do not have a common
owner are usually expressed by the element definining the class at
the source end containing a proxy that links to an external document.
Direct containment is possible but may result in duplicated data.

While tools can decide to either combine information into a single
XML document or to place information into arbitrary files, using XMI
proxies to link to that information, it is expected that some model
elements usually appear as the outermost document element of a
standalone XML file. These commonly used descriptors are assigned
descriptive terms and standard file extensions.

• A Component Package Descriptor contains a ComponentPackageDescription
  document element; it has the ".cpd" file extension.

• A Component Implementation Descriptor contains a
  ComponentImplementationDescription document element; it has the
  ".cid" file extension.

• An Implementation Artifact Descriptor contains an
  ImplementationArtifactDescription document element; it has the
  ".iad" file extension.

• A Component Interface Descriptor contains a
  ComponentInterfaceDescription document element; it has the
  ".ccd" (CORBA Component Descriptor) file extension.

• A Domain Descriptor contains a Domain document element; it has
  the ".cdd" (Component Domain Descriptor) file extension.

• A Deployment Plan Descriptor contains a DeploymentPlan document
  element; it has the ".cdp" (Component Deployment Plan) file
  extension.

• A Toplevel Package Descriptor contains a
  ToplevelPackageDescription document element; it has the
  "package.pcd" file name.

• Package files use the ".cpk" extension.

Spreading information across files according to these patterns
allow better reuse, for example by extracting an implementation
from a package.

Proxies follow the linking semantics specified by XMI. If a URI
reference does not contain a fragment identifier (the "#id_value"
part), then the target of the reference is the outermost document
element of an descriptor file. If the link attribute of a
ComponentPackageDescription proxy that is part of a
SubcomponentInstantiationDescription element does not contain
a fragment identifier, then the referenced file can be either
a Component Package Descriptor or a package (i.e. a ZIP file
with the ".cpk" extension containing the package).

If a proxy's URIs consists of a relative path (using the rel_path
branch in the URI BNF), then it is interpreted relative to the
directory that the current document is in. URIs that consist of
an absolute path (using the abs_path branch in the URI BNF) are
interpreted relative to the current package.

If a proxy's URI reference is a relative path, then the referenced
file is looked for in the same directory as the document that
contains the referencing element. If the URI reference is an absolute
path, then the referenced file is looked for in the same package as
the document that contains the referencing element.

For backward compatibility, if the target of a proxy link does not
exist, it will also be looked for under a top level "meta-inf"
directory.

Change the Mapping to XML section to read

After applying the transformations defined in this section, an XML
Schema is generated by applying the rules set forth in the XML
Metadata Interchange specifcation, chapter 2, "XML Schema Production."

Delete section 6.6, "Mapping Discussion."

Delete chapter 7, "Mapping to XML Schema."