DDS-XTypes 1.0b2 FTF Avatar
  1. OMG Issue

DDSXTY — XML representations should define namespaces

  • Key: DDSXTY-19
  • Legacy Issue Number: 15699
  • Status: closed  
  • Source: DECA ( Rick Warren)
  • Summary:

    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.

  • Reported: DDS-XTypes 1.0b1 — Fri, 8 Oct 2010 04:00 GMT
  • Disposition: Resolved — DDS-XTypes 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT