DDSXTY — XML representations should define namespaces

Currently, the XML Type Representation and XML Data Representation do not define XML namespaces. This omission prevents XML documents of these types from being used in certain contexts, such as within XML catalogs or SOAP messages.
Resolution:
1. Specify the XML namespace for the XML Type Representation. This namespace shall be formed by appending the OMG document number of the specification to the OMG HTTP domain in the following way: http://www.omg.org/<TF or TC>/<year>/<month>/<document ordinal>/<section_name>. For example, the namespace for the beta 1 specification would be: http://www.omg.org/ptc/2010/05/12/XML_Type_Representation.
2. Allow the association of a target namespace with the XSD Type Representation of a set of types, such that documents conforming to such type definitions may be properly validated against that namespace. This target namespace will be implied by the fully qualified name of each non-nested type, such that all DDS types, regardless of which Type Representation was used to define them, implicitly define a target namespace that can be used to validate XML Data Representation documentsThis mechanism will be specific to the XSD Type Representation; the concept of a target XML namespace will not be promoted into the Type System (or, by extension, into other Type Representations). (This implied target namespace will be a URN, not a URL; it will not be possible to dereference it.)
2.3. Allow applications the choice of whether to include XML namespaces on the network. Split the XML Data Representation into two dialects: XML_VALID and XML_WELL_FORMED. The former will include explicit namespace declarations and properly qualify all element and attribute names. The latter will, for the sake of compactness, omit namespace information.

1. Specify the XML namespace for the XML Type Representation. This
namespace shall be formed by appending the OMG document number of the
specification to the OMG HTTP domain in the following way:
http://www.omg.org/<TF or TC>/<year>/<month>/<document
ordinal>/<section_name>. For example, the namespace for the beta 1
specification would be:
http://www.omg.org/ptc/2010/05/12/XML_Type_Representation.
2. Allow the association of a target namespace with the XSD Type
Representation of a set of types, such that documents conforming to such
type definitions may be properly validated against that namespace. If this
target namespace is not specified explicitly, it shall be implied by the fully
qualified name of each module, such that all DDS types, regardless of which
Type Representation was used to define them, implicitly define a target
namespace that can be used to validate XML Data Representation
documents. The implied namespace shall take the form
ddstype://www.omg.org/<module path>, where <module path> is a
list of enclosing modules, separated by forward slashes, from outermost to
innermost. (Note that this implied target namespace is a URN, not a URL; it
will not be possible to dereference it.)
3. Allow applications the choice of whether to include XML namespaces on the
network. Split the XML Data Representation into two dialects: “valid” and “well
formed.” The former will include explicit namespace declarations and properly
qualify all element and attribute names. The latter will, for the sake of
compactness, omit namespace information.
With respect to (#2), the ability of an XSD author to explicitly specify a target
namespace—rather than relying on a module-based implied namespace—is
important to retain compatibility with the CORBA to WSDL/SOAP Interworking
Specification, on which the XSD Type Representation depends. The authors of
that specification explicitly chose not to support module-based namespaces for
performance reasons, as described in section 4.1.4 of that specification.