The machine-readable file URLs on the
FTF report (ptc/15-09-21) and FTF 2 convenience document
(ptc/15-09-13) disagree.

The correct ones are the ones used in the FTF 2 document because these are consistent which the reference schema files that appear in the XML files also included as part of the specification.

If nothing is done the URLs on the cover of the report (ptc/15-09-21) take precedence over the ones in the FTF2 specification, so it is imperative to re-issue the report to correct this.

This issue proposes a minor enhancement/correction to the resolution in http://solitaire.omg.org/browse/DDSWEB-20 to account for the name changes introduced in the resolution of DDSWEB-1.

These changes apply to the new section 8.3.5.2 added by the resolution of DDSWEB-3 / DDSWEB-20

In the Table at the end of 8.3.5.2 before 8.3.5.2.1 replace element name
dds.dataset_library_dataset.readSampleSeq with
dds.dataset_library_dataset.read_sample_seq

In the same Table, replace element name
dds.dataset_library_dataset.writeSampleSeq with
dds.dataset_library_dataset.write_sample_seq

On section 8.3.5.2.1 Under XML preparation, item number 2. Append the following sentence at the end of that item:

Schema name-space (xmlns) and location (schemaLocation, noNamespaceSchemaLocation) attributes are discarded.

On section 8.3.5.2.1 Under Transformation rules, item number 4.4.1. Add the sub-item 4.4.1.1 with contents:

4.4.1.1 If the resulting attribute name matches the element_name_property (see 4.4.2) then the property name is constructed as the concatenation of “@”, the element name, and the attribute name.

Make requested enhancements

Accept proposed changes and also make adjustments to the non-normative file webdds_rest1_example.xml to include the results of the change. Also adjust schema locations on webdds_rest1.xsd

Changes to webdds_rest1_example.xml are:

Change of xsi:noNamespaceSchemaLocation from:
xsi:noNamespaceSchemaLocation="webdds_rest1.xsd"
To
xsi:noNamespaceSchemaLocation="http://www.omg.org/spec/DDS-WEB/20150901/webdds_rest1.xsd"

Change of xsi:schemaLocation from:
xsi:schemaLocation="http://www.omg.org/dds/ webdds_rest1.xsd"
To
xsi:schemaLocation="http://www.omg.org/dds/ http://www.omg.org/spec/DDS-WEB/20150901/webdds_rest1.xsd"
Rename element <ShapeType> nested inside <dataset_library> to <ShapeStruct> this happens in 3 places.

Changes to webdds_rest1.xsd are:
Change of xsi:schemaLocation from:
<xs:include schemaLocation="DDS_QoSProfile.xsd"/>
To:
<xs:include schemaLocation="http://www.omg.org/spec/dds4ccm/20110201/DDS_QoSProfile.xsd"/>

Change of xsi:schemaLocation from:
<xs:import
schemaLocation="dds-xtypes_type_definition.xsd"
namespace="http://www.omg.org/ptc/2011/01/07/XML_Type_Representation/"/>
To:
<xs:import
schemaLocation="http://www.omg.org/spec/DDS-XTypes/20120202/dds-xtypes_type_definition.xsd"
namespace="http://www.omg.org/ptc/2011/01/07/XML_Type_Representation/"/>

In Page 63 – section 8.3.2) the ReturnCode for the DDS_ERROR is not specified. A suitable value could be 500 “Internal Server Error". (same we do for GENERIC_SERVER_ERROR)

Add mapping from DDS_ERROR to HTTP status 500

At the bottom of Section 8.3.2 add another bullet following all the ones already there:

• ReturnCode DDS_ERROR shall be mapped to HTTP status 500 Internal Server Error

Table 5 in Section 8.3.3 lists the resource representations that appear in the bodies of the REST operations and Table 6 specifies the location in the XSD where those representations are defined.
However the references to the XSD in Table 6 point to the definition of a “type” inside the XSD (for example participantObjectRepresentation points to the xs:complexType named “DomainParticipant”). It would be better if the specification of the representation was done in terms of an XML element (of an XSD-defined type) rather than in terms of the type itself. If the specification is done referencing just the XSD type the resulting definition does not specify an outer XML element name. This is ambiguous and could be interpreted as implying that there is no outer XML element (e.g. the information appears directly inside <body> section of the HTML). If the definition was done using an XSD element, the resource representation would appear inside a single XSD element facilitating parsing and avoiding potentially conflicting interpretations of the specification.
In addition applicationRepresentation and qosRepresentation appear in webdds_rest1.xsd but are missing from section 8.3.4. They should be added to 8.3.4.
Also missing is the definition of a list of participantObjectRepresentation and list of typeObjectRepresentation.
The reference to DDS-XTYPES in Table 6, second row is incorrect. The referenced schema is in webdds_rest1.xsd, not DDS-XTYPES.

Align section 8.3.4 with the XSD

Align section 8.3.4 with the XSD. This means:

• Update Table 5 and changing the “HTTP request and response bodies” column in the places where it says “List of <someObjectRepresentation>” to saying “<someObjectRepresentation>List” this applies to:
  • List of participantObjectRepresentation
  • List of typeObjectRepresentation
  • List of waitsetObjectRepresentation
  • List of registerTypeObjectRepresentation
  • List of topicObjectRepresentation
  • List of publisherObjectRepresentation
  • List of subscriberObjectRepresentation
  • List of datawriterObjectRepresentation
  • List of dataReaderObjectRepresentation
  • List of dataSampleRepresentation, except this should be changed to readSampleList intstead of dataSampleRepresentationList

• Modify Table 6 adding adding participantObjectRepresentationList, applicationObjectRepresentation, applicationObjectRepresentationList, qosLibraryObjectRepresentation, qosLibraryObjectRepresentationList, qosProfileObjectRepresentation, and qosProfileObjectRepresentationList.

• Modify Table 6 second column ( “Format for the object representation” ) so the object representation is defined as an XML element based on types in webdds_rest1.xsd rather than defined as an XSD type directly.

The XSD uses the element name "domain_participant" while the REST resources refer to it as "participant". The two should be aligned.

In some places of the document it refers to the different content types as webdds+xml and wendds+json. Other parts of the document use dde-web+xml and dds-web+json for essentially the same. These should be aligned.

Correct the naming inconsistencies

Use "domain_participant" for the resource URIs instead of "participant"

Use "dds-web+xml" instead of "webdds+xml"

This resolution shall apply after all other issue resolutions have been applied.

Section 8.5 “Transport-LevelProtocolConsiderations” paragraph 4 states that WebSockets can optionally be used. Specifically it says”
“As an option implementers may support upgrading the connection to using WebSockets in compliance with IETF 6455 (The WebSocket Protocol) [14].”

However this information is not sufficient to ensure implementers of the specification manage the connection and stream the content in an interoperable way. Assume for example that a particular HTTP connection is upgraded to WebSockets. When is that connection closed? Does the client still need to issue a reparate “GET” operation to keep reading data or can data continue to be streamed from the server back to the client as it arrived on a DDS DataReader?

These issues should be clarified to ensure interoperability independently of the implementation of the specification.

Add description of WebSocket transport

The main priority is to provide a way write and read DDS data using WebSockets. These are the performance-critical operations. The remaining operations, namely creation and deletion of entities, definition of data-types, QoS settings, etc., could continue to use the HTTP-based REST API.

The resolution of this issue should allow information flow over WebSockets using one or more TCP connections.

The resolution of this issue should be applied after the resolution of issue WEBDDS-7 which modified section 8.5 to clarify how to do secure HTTPS.

mars/13-05-21 introduces a dependency on X-Types making this specification only implementable by DDS vendors that support X-Types.

This dependency is superfluous and should be removed

Reject issue as the claim of requiring compliance with DDS-XTYPES is not correct

An implementation compliant with DDS-WEB is not required to implement or comply with DDS-XTYPES. The dependency on DDS-XTYPES is simply a reuse of some syntactic elements, specifically the syntax of the XML description of types and data.

It is entirely possible to comply with DDS-WEB and not implement DD-XTYPES all it is required is to understand the syntax of those XML documents and implement the proper parsers.

Stated differently the dependency on DDS-XTYPES is similar to the dependency on other specifications like as dds4ccm, the IDL, XML, and XSD specifications. It just points to specific document syntax defined on those specifications to avoid duplicating that syntax in the DDS-WEB specification.

The mars/13-05-21 introduces an AccessController, yet it is not clear how this relates to DDS security access control plug-in.

Clarify AccessControl class and relationship to DDS-Security

The confusion stems from modeling the client application as a "User" rather than simply a client. Also the requirement for a login/logout transaction is not what typical rest-api users are accustomed to. In most API's the authentication is tied to some API key/token that is passed as part of each request. That way the server does not need to retain session information.

To clarify this the revised text renames "User" to "Client" and introduces a REST-API-Key explaining how it is included in the HTTP headers It also specifies how this mechanism leverages the security mechanisms built in HTTPS.
The change is not very large in terms of the rest protocol itself. But a lot of text and figures are affected by the rename.
The new figures are not attached to this resolution because there is another issue (DDSWEB-21) that will update most of the figures so it would be redundant to attach the figures twice. The changes to the figures are nevertheless listed as part of the revised text.

Today the term "Web Applications" usually refers to HTML5/JavaScript applications. Assuming this mainstream interpretation, the mars/13-05-21 is not at all providing "Web-Enabled DDS".

This recommended specification should be split into a W3C and a REST PSM for DDS. In any case the name should be updated accordingly to avoid confusing end-users, claiming "Web-Enabled" when the mars/13-05-21 is really "Web-Disabled".

No changes needed the name seems appropriate

The specification defines the means for applications using standard web protocols (HTTP/REST) to participate as first-class citizens as publishers and subscribers of data in the DDS Global Data space. This participation is realized by exposing a WebDDS Object Model and making it accessible via web-protocols as a set of REST resources, or some other standard web protocols (e.g. SOAP).

The specification therefore enables applications built on various web technology stacks (e.g. JavaScript, Python, PHP, Perl , etc.) to communicate with native DDS applications. So the name "web enabled DDS" is precise and appropriate.

The mars/13-05-21 uses WEBDDS as a namespace for everything. This is perseverating the orinignal sin of the DDS specification using DDS as nanespace.

This fragile use of namespaces should be replaces with the same style used now by the new Java/C++ PSM. mars/13-05-21 should use something like:

org.omg.dds.xyz

Reject change as these classes are purely descriptive and do not appear in any user-visible APIs

These name spaces are only in the conceptual model of how the service works. They are not reflected in any user-visible objects or APIs. '

A compliant implementation of the specification is not forced to use any of these classes or to name them according to the name used in the specification.

For this reason there is no need to make any changes to the specification.

The acknowledgment page include PrismTech. This should be removed as PrismTech – who was clearly against this specification – does not want to be claimed as supporting it in any form.

This specification is of doubtful use and does not reflect in any mean or form PrismTech vision on what Web-Enabled really is.

Remove PrismTech from section 6.2 Acknowledgements

In Section 6.2 remove the second bullet that says:

• PrismTech

The sumission is using a PrismTech copyrighted picture w/o asking permission.

Notice that PrismTech is not part of the submission. This should be addressed ASAP by the submitters as they are in violation of copyright rules.

Replace figure 1

Replace Figure 1 with the one attached

The specification documents are all under the namespace: http://www.omg.org/spec/DDS-WEB/20131122
Whereas the XSD documents use targetNamespace that use different prefixes:

webdds_rest1.xsd sets targetNamespace="http://www.omg.org/spec/WEBDDS/20130601/"

webdds_soap1_types.xsd sets targetNamespace="http://www.omg.org/webdds/"
webdds_soap1.wsdl sets targetNamespace ="http://www.omg.org/spec/WEBDDS/20130601/
webdds_soap1_notify.wsdl sets targetNamespace ="http://www.omg.org/spec/WEBDDS/20130601/

While this is technically allowed it is likely to cause confusion because the xmlns used in an XML must match the targetNamespace of the referenced XSD.

For this reason it would be better that the three targetNamespace are consistent. For example, assume that the result of the FTF has the machine-readable documents under the URL prefix:
http://www.omg.org/spec/DDS-WEB/20140901/

Then the XSD documents should all use the same target namespace "http://www.omg.org/spec/DDS-WEB/20140901/"

Note that it is allowed for multiple schemas to have the same targetNamespace and it is one of the recommended practices when all the schemas are conceptually related and there is no need to separate identify the origin/lineage of each element.

Resolve by updating the schema file webdds_rest1.xsd and the non-normative example file webdds_rest1_example.xml

This issue is addresses by updating the XSD shema file (webdds_rest1.xsd ) and the the non-normative example file webdds_rest1_example.xml

The two files are attached. Replacing this two files is the only change to the specification to address the issue.

What follows is the detailed description of the changes performed to those files and the reasons for them.

• To increase the usability of the XSD the namespaces and imports should be re-organized. The webdds_rest1.xsd schema declaration should be modified to use http://www.omg.org/dds/ as the target namespace. The result should be as follows:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns="http://www.omg.org/dds/" 
           xmlns:dds="http://www.omg.org/dds/" 
           xmlns:xtypes="http://www.omg.org/ptc/2011/01/07/XML_Type_Representation/" 
           targetNamespace="http://www.omg.org/dds/" 
           elementFormDefault="qualified"
           attributeFormDefault="unqualified">

• The import of DDS_QoSProfile.xsd in the webdds_rest1.xsd should be changed to a “include”.
  Also note the issue filed to change the definition of elementName:

       
      <!-- Issue filed on DDS4CCM (DDS_QoSProfile.xsd) change definition of elementName
           to <xs:pattern value="([a-zA-Z0-9_.])+" />
           Also make it into a Chameleon schema
      -->
      <xs:include	schemaLocation="DDS_QoSProfile.xsd"/>
  

This issue also impacts the XML files associated with that schema file should be modified accordingly.

• The root element for webdds_rest1_example.xml and elements xmlns, xmlns:dds, xmlns:xtype, and xsi:schemaLocation should be modified to match what is shown below:

  <!-- This is file webdds_rest1_example.xml -->
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://www.omg.org/dds/"
      xsi:schemaLocation="http://www.omg.org/dds/    http://www.omg.org/spec/DDS-WEB/20150901/webdds_rest1.xsd"
   

• Consistently follow snake_case naming convention for the element names in the XSD. Rename all CamelCase to snake_case for the XSD elements. The XSD types can remain in CamelCase. This renames webdds_rest1.xsd XSD elements:

  sourceTimestamp, instanceHandle, validData, instanceState, sampleState, viewState, readSampleInfo, sampleData, writeSampleInfo, returnCode, returnMessage, accessToken, sessionId.

  To:

  source_timestamp, instance_handle, valid_data, instance_state, sample_state, view_state, read_sample_info, sample_data, write_sample_info, return_code, return_message, access_token, session_id.

• Consistently use lower case for all type definitions in the XSD with CamelCase convention.
  This rename webdds_rest1.xsd XSD types:

  RegisterType, Topic, TopicList, DataWriter, DataWriterList, DataReader, DataReaderList, Publisher, PublisherList, Subscriber, SubscriberList, DomainParticipant, DomainParticipantLibrary, StatusCondition, ReadCondition, ContentFilter, ParameterList, Waitset, ReturnStatus, Application, AuthenticatedSession

  To:

  registerType, topic, topicList, dataWriter, dataWriterList, dataReader, dataReaderList, publisher, publisherList, subscriber, subscriberList, domainParticipant, domainParticipantLibrary, statusCondition, readCondition, contentFilter, parameterList, waitset, returnStatus, application, authenticatedSession

• Introduce the following new definition on the webdds_rest1.xsd XSD:

      <xs:simpleType name="elementNameReference">
          <xs:restriction base="xs:string">
              <xs:whiteSpace value="collapse"/>
              <xs:pattern value="((::)?[a-zA-Z0-9_.])+"/>
          </xs:restriction>
      </xs:simpleType>
  

• Change the type of the “_ref” attributes (type_ref, register_type_ref, topic_ref), from “dds:elementName” to “elementNameReference”.
  Change the type of the “base_name” attribute on element domainParticipant to “elementNameReference”.

• Change all type attributes in the elements of webdds_rest1.xsd that refer to types defined in DDS_QoSProfile.xsd. Currently all these references have the prefix “dds:” drop that prefix since the target namespace is now the same. Effectively this removes all the “dds:” from the values of the “type=” attribute.

• Rename the webdds_rest1.xsd XSD types “Sample” and “SampleSeq” to “readSample” and “readSampleSeq” also changing the definition of “Sample” to use “xs:any” and “data” as an element name so the the type “xs:Sample” becomes:

       <xs:complexType name="anyDataValue">
  		<xs:sequence>
  			<xs:any processContents="lax" minOccurs="1" maxOccurs="1"/>
  		</xs:sequence>
       </xs:complexType>
  
      <xs:complexType name="readSample">
          <xs:sequence>
              <xs:element name="readSampleInfo" type="readSampleInfo" 
                                  minOccurs="0" maxOccurs="1"/>
              <xs:element name="data" type="anyDataValue" minOccurs="0" maxOccurs="1"/>
          </xs:sequence>
      </xs:complexType>
  

• Add the following definitions to the webdds_rest1.xsd XSD:

     <xs:complexType name="writeSample">
          <xs:sequence>
              <xs:element name="write_sample_info" type="writeSampleInfo" minOccurs="0" maxOccurs="1"/>
              <xs:element name="data" type="anyDataValue" minOccurs="0" maxOccurs="1"/>
          </xs:sequence>
      </xs:complexType>
      
       <xs:complexType name="writeSampleSeq">
          <xs:sequence>
              <xs:element name="sample" type="writeSample" minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
      </xs:complexType>
  
      <xs:complexType name="writeSampleSeq">
          <xs:sequence>
              <xs:element name="sample" type="writeSample" minOccurs="0" maxOccurs="unbounded"/>
          </xs:sequence>
      </xs:complexType>
  

• Modify the definition of application to match what follows. Remove unused type authenticatedSession from webdds_rest1.xsd

     <xs:complexType name="application">
        <xs:annotation>
          <xs:documentation xml:lang="en-US">
            The Application is a a collection of domain participants they can refer to participants
            in a domain_partitipant_library by the inheritance provided by the base_name attribute
          </xs:documentation>
        </xs:annotation>
        <xs:choice maxOccurs="unbounded">
          <xs:element name="domain_participant" maxOccurs="unbounded" type="domainParticipant"/>
        </xs:choice>
        <xs:attribute name="name" type="elementName" use="required"/>
      </xs:complexType>
  

• Add types qosLibraryList, qosProfileList, applicationList, domainParticipantList, to webdds_rest1.xsd

  <!-- definitions to be added to webdds_rest1.xsd -->
   <xs:complexType name="applicationList">
         <xs:sequence minOccurs="0" maxOccurs="unbounded">
             <xs:element name="application" minOccurs="0" type="application"/>
         </xs:sequence>
      </xs:complexType>  
  
   <xs:complexType name="qosLibraryList">
         <xs:sequence minOccurs="0" maxOccurs="unbounded">
             <xs:element name="qos_library" minOccurs="0" type="qosLibrary"/>
         </xs:sequence>
      </xs:complexType>    
    
  <xs:complexType name="qosProfileList">
         <xs:sequence minOccurs="0" maxOccurs="unbounded">
             <xs:element name="qos_profile" minOccurs="0" type="qosProfile"/>
         </xs:sequence>
      </xs:complexType>    
  
  <xs:complexType name="domainParticipantList">
         <xs:sequence minOccurs="0" maxOccurs="unbounded">
             <xs:element name="domain_participant" minOccurs="0" type="domainParticipant"/>
         </xs:sequence>
      </xs:complexType>    
  

• Add types dataset and datasetLibrary to the webdds_rest1.xsd XSD.

   <!--  ======================================================================== -->
      <xs:complexType name="dataset">
          <xs:all  minOccurs="0" maxOccurs="1">  
              <xs:element name="read_sample_seq" type="readSampleSeq" minOccurs="0" maxOccurs="1" />
              <xs:element name="write_sample_seq" type="writeSampleSeq"  minOccurs="0" maxOccurs="1" />
          </xs:all>
          <xs:attribute name="name" type="elementName" use="required"/>
      </xs:complexType>
      
      <xs:complexType name="datasetLibrary">
          <xs:annotation>
              <xs:documentation>
                  Contains Collections of data samples
              </xs:documentation>
          </xs:annotation>
          <xs:sequence>
              <xs:choice maxOccurs="unbounded">
                  <xs:element name="dataset" type="dataset" minOccurs="0" maxOccurs="unbounded"/>
              </xs:choice>
          </xs:sequence>
          <xs:attribute name="name" type="elementName" use="required"/>
      </xs:complexType>
  

• Modify webdds_rest1.xsd XSD as follows
  Rename element “restdds” to “dds”
  Modify the type “dataReader” moving the documentation annotation on the “query_condition” element to the “content_filter” element.
  Rename the type “contentFilter” to “filter” and modify documentation accordingly
  Remove the type definitions for instanceState, viewState, and sampleState. Change references the these types in type readSampleInfo to instanceStateKind, viewStateKind, and sampleStateKind, respectively. Change also readSampleInfo type so that so that minOccurs of any of the child elements 0 instead of 1. The resulting readSampleInfo type should match this:

<xs:complexType name="readSampleInfo">
        <xs:all>
            <xs:element name="source_timestamp" type="time" minOccurs="0" maxOccurs="1"/>
            <xs:element name="valid_data" type="xs:boolean" minOccurs="0" maxOccurs="1"/>
            <xs:element name="instance_handle" type="instanceHandle" minOccurs="0" maxOccurs="1"/>
            <xs:element name="instance_state" type="instanceStateKind" minOccurs="0" maxOccurs="1"/>
            <xs:element name="sample_state" type="sampleStateKind" minOccurs="0" maxOccurs="1"/>
            <xs:element name="view_state" type="viewStateKind" minOccurs="0" maxOccurs="1"/>
        </xs:all>
    </xs:complexType>

Modify the definition of the “registerType” type adding a “format” attribute.

   <xs:attribute name="format" type="xs:string" use="optional">
          <xs:annotation>
              <xs:documentation>
                  Format used to read/write data of this type. If left unspecified
                  the default format is “XML”
               </xs:documentation>
           </xs:annotation>
        </xs:attribute>

• Modify the definition of element “condition” within type “waitset” adding an intermediate “waitsetCondition” type that is just a reference to a condition. The added waitsetCondition and modified waitset is:

     <xs:complexType name="waitsetCondition">
              <xs:attribute name="condition_ref" type="elementNameReference" use="required">
             <xs:annotation>
                <xs:documentation xml:lang="en-US">
                    Must refer to a condition associated with a DDS entity
                </xs:documentation>
             </xs:annotation>
          </xs:attribute>
      </xs:complexType>
      
      <xs:complexType name="waitset">
          <xs:sequence>
              <xs:element name="condition" type="waitsetCondition"/>
          </xs:sequence> 
          <xs:attribute name="name" type="elementName" use="required"/>                      
      </xs:complexType>
   

• Modify the restdds element of webdds_rest1_example.xml to include the additional children and also to refer to the xtypes:types element directly. The resulting element is:

     <xs:element name="dds">
          <xs:complexType>
              <xs:sequence>
                   <xs:choice maxOccurs="unbounded">
                      <xs:element name="qos_library" type="qosLibrary" minOccurs="0" maxOccurs="unbounded"/>
                      <xs:element ref="xtypes:types" minOccurs="0" maxOccurs="unbounded"/>
                      <xs:element name="waitset_library" type="waitsetLibrary" minOccurs="0" maxOccurs="unbounded"/>                   
                      <xs:element name="domain_participant_library" type="domainParticipantLibrary" maxOccurs="unbounded"/>
                      <xs:element name="application" type="application"  maxOccurs="unbounded"/>
                      <xs:element name="dataset_library" type="datasetLibrary" maxOccurs="unbounded"/>
                  </xs:choice>
              </xs:sequence>        
          </xs:complexType>
      </xs:element>
  

• Modify the non-normative webdds_rest1_example.xml to match the changes in the XSD. Also add example use for more of the elements defined in the XSD, this means adding examples for qos_library, dataset, waitset_library. Also change the type “ShapeType” to be inside a module.

There is no description of QosProfiles and Types in section 7.4 where all the other DDS proxy classes are described.

There are no mappings of QosProfiles and Types to the REST platform in section 8.3.3 nor to the SOAP platform in section 8.4 Table 9 .

QoS profiles are scoped inside applications in section 8.3.1. This is inconsistent with the XSD where they appear inside a “qosLibrary” element.

Types are scoped inside applications. This is inconsistent with the XSD where they appear inside the root “restdds”.

Also the name WSDDS should we changed so something better. “WSDDS” has no meaning as it is not a “web service”. In the specification is used to name specific singleton object that serves as a way to bootstrap the system. Hence a better name would be WebDDS::Root. This only affects the conceptual model. It has no user-visible effect on the the exposed APIs and protocols.

Update UML model with additional classes. Add missing operations and update Table 5

Make the following changes to the UML model.

• Change the name of class WebDDS::WSDDS to WebDDS::Root
• Introduce a WebDDS::QosLibrary class owned by WedDDS::Root
• Move class WebDDS::QosProfile from its current owner (Applications) to be owned by WebDDS::QosLibrary
• Move class WebDDS::Type from its current owner (Applications) to be owned by WebDDS::Root.
• Add new operations to WebDDS::Root: get_applications, create_qos_library, delete_qos_library, get_qos_libraries,
• Move operations create_type, delete_type, get_type from WebDDS::Application to WebDDS::Root
• Remove the relationships from WebDDS::Application to WebDDS::Type and WebDDS::QosProfile. Instead there should be “uses” relationships from WebDDS::Participant to those classes.

Regenerate figures 3, 4, 6, 7, 8, 9, 10, and 11. Such that they include the above-listed changes. The new figures are attached to this issue resolution.

Change the specification where it mentions object “WSDDS”. Replace that with either “WebDDS::Root” or “WebDDS” as described below:

• Section 7.2 (2 times)
• Section 7.3 (4 times) the first 2 replace with “WebDDS::Root” the second two replace with “WebDDS”
• Title of section 7.3.1. Change title to “Class WebDDS::Root”
• Figure 7 caption change “WSDDS” to “WebDDS::Root”
• Section 7.3.3 change “WSDDS” to “WebDDS::Root”
• Table 5, (2 times) change “WSDDS” to “WebDDS::Root”
• Section 8.4 change “WSDDS” to “WebDDS::Root”

Modify section 7.3.1 as specified below:

• Rename WebDDS::Root class operations “login” to “create_application”.
• Rename WebDDS::Root class operations “logout” to “delete_application”.

Modify section 7.3.1 first paragraph:
Change:
The WSDDS singleton directly manages three kinds of objects: Users, Applications, and AccessController.

To:
The WebDDS::Root singleton directly manages five kinds of objects: Client, Application, Type, QosLibrary, and AccessController.

Add The following subsections to 7.3.1
* 7.3.1.3 Operation: get_applications
* 7.3.1.4 Operation: create_qos_library
* 7.3.1.5 Operation delete_qos_library,
* 7.3.1.6 Operation: get_qos_libraries
These subsection appear in the attachment file subsections_7313_to_7316.docx

Move operations: create_type , delete_type, get_type from WebDDS::Application to WebDDS::Root. create_type moves from section 7.4.3.4 to section 7.3.1.7. Operation delete_type moves from section 7.4.3.5 to section 7.3.1.8. Operation get_type moves from section 7.4.3.6 to section 7.3.1.9.

Modify operation create_type (new section 7.3.1.7) to match the attached file webdds_section_7317.docx

Modify 7.3.1.8 Operation: delete_type
Replace last sentence:
It deletes the located WebDDS::Type and the associated DDS:DynamicType object.

With:
It deletes the located WebDDS::Type object. If the operation succeeds it returns OK. Otherwise it returns GENERIC_SERVICE_ERROR.

Modify 7.3.1.9 Operation: get_type.
Change the name to “get_types” and replace description with that of the attached file webdds_section_7319.docx

Add section 7.4.10 with the text in the attached file webdds_section_7410.docx :

Add section 7.4.11 with the text below:
7.4.11 Class WebDDS::QosProfile
This class represents a Qos Profile as defined in the DDS4CCM specification (http://www.omg.org/spec/dds4ccm/) version 1.1.

A Qos Profile is a named object containing DDS Qos definitions for each kind of DDS Entity: DomainParticipant, Topic, Publisher, Subscriber, DataWriter, and DataReader. This grouping under a single Qos Profile object enables applications to specify desired Qos by indicating only the name of the Qos Profile object to use. As DDS Entities are created the proper Qos is selected based on the kind of DDS entity.

Update Table 5 in Section 8.3.3 the REST mappings with the following changes:
Change:
Application::create_type

To:
Root::create_type

Change URI from:
/applications/<appname>/types

To:
/types

Change:
Application::delete_type

To:
Root::delete_type

Change URI from:
/applications/<appname>/types/<typename>

To:
/types/<typename>

Change:
Application::update_type

To:
Root::update_type

Add the operations in the attached webdds_table5_added_operations.docx to Table 5 in Section 8.3.3:

Table 5 in Section 8.3.3 lists the resource representations that appear in the bodies of the REST operations and Table 6 specifies the location in the XSD where those representations are defined.
However the references to the XSD in Table 6 point to the definition of a “type” inside the XSD (for example participantObjectRepresentation points to the xs:complexType named “DomainParticipant”). It would be better if the specification of the representation was done in terms of an XML element (of an XSD-defined type) rather than in terms of the type itself. If the specification is done referencing just the XSD type the resulting definition does not specify an outer XML element name. This is ambiguous and could be interpreted as implying that there is no outer XML element (e.g. the information appears directly inside <body> section of the HTML). If the definition was done using an XSD element, the resource representation would appear inside a single XSD element facilitating parsing and avoiding potentially conflicting interpretations of the specification.
In addition applicationRepresentation and qosRepresentation appear in webdds_rest1.xsd but are missing from section 8.3.4. They should be added to 8.3.4.
Also missing is the definition of a list of participantObjectRepresentation and list of typeObjectRepresentation.
The reference to DDS-XTYPES in Table 6, second row is incorrect. The referenced schema is in webdds_rest1.xsd, not DDS-XTYPES.

Issue duplicated DDSWEB-14

Mark as duplicate

In Page 63 – (section 8.3.2) the ReturnCode for the DDS_ERROR is not specified. A suitable value could be 500 “Internal Server Error. (same we do for GENERIC_SERVER_ERROR)

Duplicates DDSWEB-9

This entry is duplicated

Section 7.4.8.1 describes the operation “get” on a DataReader and describes the behavior when the sampleSelector is a pure “FilterExpression” or a pure “MetadataExpression” however the SampleSelector can be an expression that combines both a FilterExpression and a MetadataExpression and the behavior on that situation is not specified.

In addition on that section Case 3. It says:
“Case 3: If the sampleSelector is a FilterExpression, then the operation uses the MetadataExpression …”
where it really should say:
“Case 3: If the sampleSelector is a MetadataExpression, then the operation uses the MetadataExpression …”

In addition the MetadataExpression can include an expression on the InstanceHandle. This case is also not described.

*Extend description of the GET operation to capture all the cases where there is both a FilterExpression and a MetadataExpression *

Edit the description in section 7.4.8.1 per the instructions below.

Change “FilterExpression or MetadataExpression” to “FilterExpression, MetadataExpression, or both” in the sentence below:
It parses the sampleSelector to determine if it is a DDS FilterExpression or MetadataExpression, MetadataExpression, or both. If there is a parse error, it returns the INVALID_INPUT error.

Change “three” to “four” and “or it contains a MetadataExpression.” to “a MetadataExpression, or both” in the sentence below:
There are fourthree possible cases depending on whether the sampleSelector is empty, it contains a FilterExpression, or it contains a MetadataExpression. a MetadataExpression, or both.

Replace Case 3 with the text below:
Case 3: If the sampleSelector is a MetadataExpression there are two situations:

3.1 If the MetadataExpression does not contain an InstanceHandleExpr, then the operation uses the MetadataExpression to deduce the desired sample_state, view_state, and instance_state. These states are used as parameters to calling read and/or take to obtain samples that match the desired states. Other than this the logic is the same as in Case 1.

3.2 If the MetadataExpression contains the InstanceHandleExpr, then the InstanceHandleExpr is analyzed to deduce the desired InstanceHandle objects. The rest of the MetadataExpression is analyzed as described in case 3.1 to also derive the desired sample/view/instance states. These parameters are used in multiple calls to read_instance or take_instance passing each of the desired InstanceHandle objects and the desired sample/view/instance states. Other than this the logic is the same as in Case 1.

Add Case 4 as written below:
Case 4: If the sampleSelector contains both a FilterExpression and a MetadataExpression then there are two situations:

4.1 If MetadataExpression does not contain an InstanceHandleExpr, then the operation uses the MetadataExpression to deduce the desired sample/state/view states. There are two possibilities:
4.1.1 If the logical operation between the MetadataExpression and the FilterExpression is AND, then the operation constructs a QueryCondition using the FilterExpression from the sampleSelector and the desired sample/state/view states and proceeds as in Case 2.
4.1.2 If the logical operation between the MetadataExpression and the FilterExpression is OR, then the operation constructs a QueryCondition using the FilterExpression from the sampleSelector and leaving the states as "any". In addition it also creates a ReadCondition using the desired sample/state/view states. The operation uses the two conditions separately to call read_w_condition (or take_w_condition) separately using the ReadCondition and QueryCondition and then join the results. The management of the minSamples and maxWait parameters is the same as per Case 1.

4.2 If the MetadataExpression contains the InstanceHandleExpr, then the InstanceHandleExpr is analyzed to deduce the desired InstanceHandle objects.
4.2.1 If the logical operation between the MetadataExpression and the FilterExpression is AND the operation constructs a QueryCondition using the FilterExpression and the desired sample/state/view states similar to 4.1.1. The operation then calls read_instance_w_condition (or take_instance_w_condition) iterating over each of the instances. The results are combined. The management of the minSamples and maxWait parameters is the same as per Case 1.
4.2.2 If the logical operation between the MetadataExpression and the FilterExpression is OR, then the operation constructs a QueryCondition and the ReadCondition the same way as in 4.1.2. In addition the operation analyzes the InstanceHandleExpr to deduce the desired instances. Finally the operation calls read_instance_w_condition (or read_instance_w_condition) on each of the instances of interest passing the ReadCondition and also calls read_w_condition (or take_w_condition) passing the QueryCondition. The results are combined. The management of minSamples and maxWait parameters is the same as per Case 1.

Pratically nobody uses XML in combination with REST today, yet the mars/13-05-21 only provides for this option.

This is a critical issue that makes the submissing practically useless.

AB resolved the issue out of scope for FTF. Requested RFC process is followed instead

After some discussion the AB resolved that the issue was too big to be resolved by the FTF and should be solved via RFC instead.

AB stated the RFC process could be very short and narrow. Essentially focusing it on addressing this one issue. Henceforth the previous resolution s cancelled an this issue is left open to be closed by a future RFC.

This is the so called "Chameleon" Schema and it is best for XSDs that define "building blocks of XSD types" which may be then imported/included (included) by other XSDs.

See http://www.xfront.com/ZeroOneOrManyNamespaces.html

The issue is this. If a XSD is imported into another one that has a different target namespaces it will cause some "usability problems" in the resulting XML documents. This is only an issue when the XSD is imported in order to be a building block of the resulting XSD and is not natural for the end user to have to understand the original XSDs as separate conceptual units.

For example if we wanted to create a "dds.xsd" that used a target namespace such as http://www.omg.org/dds/ and this imports XSDs like XTYPES with target namespace http://www.omg.org/xtypes/ and dds4ccm with target namespece (http://www.omg.org/dds4ccm). Note these are not the actual namespaces in those documents. I am selecting this to simplify the description.

Then each time an element from a different namespace it would need to explicitly add the attribute xmlns to the element. This would happen for both for the included DDS_QosProfiles.xsd (it uses the namespace http://www.omg.org/dds4ccm) and for dds-xtypes_type_definition.xsd (it uses the namespace http://www.omg.org/xtypes/) the resulting references to elements in that XSD would need to specify the namespace using the "xmlns" attribute as in:
<publisher name="ShapePublisher">
<publisher_qos>
<partition xmlns="http://www.omg.org/dds4ccm/">
<name>
<element>A</element>
</name>
</partition>
<publisher_qos>
</publisher>

This is cumbersome and hard to get right for the user. Also many XML editors do not provide assistance with it. The best solution would have been for the referenced standards (DD4CCM and XTYPES) to define their XSD schemas without a targetNamespace. This would have allowed the namespace to be defined in the XSD that includes them.

This is a common approach known as using “Chameleon Schemas”. These specifications could also preserve the use of their namespace by putting the namespace in a separate XSD that “includes” the Chameleon Schema. To address this an issue should be filed against those specifications to change their schemas into Chameleon schemas.

There is no loss of generality as it is always possible to define another XSD that simply includes the Chameleon one and adds the namespace.

Pratically nobody uses XML in combination with REST today, yet the mars/13-05-21 only provides for this option.

This is a critical issue that makes the submissing practically useless.