DDS-WEB — All Issues - OMG Issue Tracker

Enhancement to resolution of DDSWEB-3 / DDSWEB-20

Key: DDSWEB-25
Status: closed
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Tue, 11 Aug 2015 07:06 GMT
Disposition: Resolved — DDS-WEB 1.0
Disposition Summary:
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/"/>
Updated: Tue, 22 Dec 2015 15:08 GMT
Attachments:
- webdds_rest1.xsd 25 kB (text/xml)
- webdds_rest1_example.xml 16 kB (application/xml)

Missing HTTP return code for DDS_ERROR

Key: DDSWEB-9
Status: closed
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
Summary:
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)
Reported: DDS-WEB 1.0b1 — Fri, 7 Aug 2015 20:53 GMT
Disposition: Resolved — DDS-WEB 1.0
Disposition Summary:
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
Updated: Tue, 22 Dec 2015 15:08 GMT

Inconsistent and incomplete specification of resource representations

Key: DDSWEB-14
Status: closed
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Mon, 10 Aug 2015 08:36 GMT
Disposition: Resolved — DDS-WEB 1.0
Disposition Summary:
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.
Updated: Tue, 22 Dec 2015 15:08 GMT
Attachments:
- webdds_table6.docx 19 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Correct minor inconsistencies in naming

Key: DDSWEB-33
Status: closed
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Thu, 20 Aug 2015 10:39 GMT
Disposition: Resolved — DDS-WEB 1.0
Disposition Summary:
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.
Updated: Tue, 22 Dec 2015 15:08 GMT

Use of WebSockets is underspecified

Key: DDSWEB-30
Status: closed
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Tue, 18 Aug 2015 03:13 GMT
Disposition: Resolved — DDS-WEB 1.0
Disposition Summary:
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.
Updated: Tue, 22 Dec 2015 15:08 GMT
Attachments:
- webdds_section_8_5.docx 45 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- webdds_websockets.xsd 4 kB (text/xml)
- webdds_websockets1.xsd 4 kB (text/xml)

X-Types Dependency

Key: DDSWEB-8
Legacy Issue Number: 19251
Status: closed
Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
Summary:
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
Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
Disposition: Closed; No Change — DDS-WEB 1.0
Disposition Summary:
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.
Updated: Tue, 22 Dec 2015 15:08 GMT

Access Control Relationship with DDS Security

Key: DDSWEB-7
Legacy Issue Number: 19250
Status: closed
Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
Summary:
The mars/13-05-21 introduces an AccessController, yet it is not clear how this relates to DDS security access control plug-in.
Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
Disposition: Resolved — DDS-WEB 1.0
Disposition Summary:
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.
Updated: Tue, 22 Dec 2015 15:08 GMT

The title of the submission is misleading

Key: DDSWEB-2
Legacy Issue Number: 19245
Status: closed
Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
Summary:
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".
Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
Disposition: Closed; No Change — DDS-WEB 1.0
Disposition Summary:
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.
Updated: Tue, 22 Dec 2015 15:08 GMT

Namespace are non aligned with new PSMs

Key: DDSWEB-6
Legacy Issue Number: 19249
Status: closed
Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
Summary:
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
Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
Disposition: Closed; No Change — DDS-WEB 1.0
Disposition Summary:
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.
Updated: Tue, 22 Dec 2015 15:08 GMT

Wrong Acknoledgment

Key: DDSWEB-5
Legacy Issue Number: 19248
Status: closed
Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
Disposition: Resolved — DDS-WEB 1.0
Disposition Summary:
Remove PrismTech from section 6.2 Acknowledgements

In Section 6.2 remove the second bullet that says:
- ~~PrismTech~~
Updated: Tue, 22 Dec 2015 15:08 GMT

Copyright Violation

Key: DDSWEB-4
Legacy Issue Number: 19247
Status: closed
Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
Disposition: Resolved — DDS-WEB 1.0
Disposition Summary:
Replace figure 1

Replace Figure 1 with the one attached
Updated: Tue, 22 Dec 2015 15:08 GMT
Attachments:
- dds-web_figure_1.png 1006 kB (image/png)

The URL prefix of the specification documents is not consistent with the XSD targetNamespace

Key: DDSWEB-1
Legacy Issue Number: 19449
Status: closed
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Wed, 4 Jun 2014 04:00 GMT
Disposition: Resolved — DDS-WEB 1.0

Disposition Summary:

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.

Updated: Tue, 22 Dec 2015 15:08 GMT
Attachments:
- webdds_rest1.xsd 25 kB (text/xml)
- webdds_rest1_example.xml 16 kB (application/xml)

Qos Profiles and Types are underspecified and inconsistent with XSD

Key: DDSWEB-21
Status: closed
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Mon, 10 Aug 2015 10:38 GMT
Disposition: Resolved — DDS-WEB 1.0
Disposition Summary:
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:
Updated: Tue, 22 Dec 2015 15:08 GMT
Attachments:
- Figure10_WebDDS_DDS-Mapping.emf 208 kB ()
- Figure11_WebDDS_Application.emf 75 kB ()
- Figure3_PIM_Overview.emf 142 kB ()
- Figure4_WebDDS_Overview.emf 60 kB ()
- Figure6_WebDDS_AppUserAccess.emf 52 kB ()
- Figure7_WebDDS_Root.emf 84 kB ()
- Figure8_WebDDS_AccessController.emf 71 kB ()
- Figure9_WebDDS_ProxyClasses.emf 142 kB ()
- webdds_section_7317.docx 16 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- webdds_section_7319.docx 16 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- webdds_section_7410.docx 18 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- webdds_sections_7313_to_7316.docx 19 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- webdds_table5_added_operations.docx 18 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Inconsistent and incomplete specification of resource representations

Key: DDSWEB-19
Status: closed
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Mon, 10 Aug 2015 09:35 GMT
Disposition: Duplicate or Merged — DDS-WEB 1.0
Disposition Summary:
Issue duplicated ~~DDSWEB-14~~

Mark as duplicate
Updated: Tue, 22 Dec 2015 15:08 GMT

Missing HTTP return code for DDS_ERROR

Key: DDSWEB-17
Status: closed
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
Summary:
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)
Reported: DDS-WEB 1.0b1 — Mon, 10 Aug 2015 09:26 GMT
Disposition: Duplicate or Merged — DDS-WEB 1.0
Disposition Summary:
Duplicates ~~DDSWEB-9~~

This entry is duplicated
Updated: Tue, 22 Dec 2015 15:08 GMT

Incomplete specification of the GET operation on the DataReader (Section 7.4.8.1)

Key: DDSWEB-29
Status: closed
Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Sat, 15 Aug 2015 02:35 GMT
Disposition: Resolved — DDS-WEB 1.0
Disposition Summary:
*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 four~~three~~ 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.
Updated: Tue, 22 Dec 2015 15:08 GMT

JSON Missing

Key: DDSWEB-3
Legacy Issue Number: 19246
Status: closed
Source: ZettaScale Technology ( Angelo Corsaro, PhD.)
Summary:
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.
Reported: DDS-WEB 1.0b1 — Fri, 21 Feb 2014 05:00 GMT
Disposition: Deferred — DDS-WEB 1.0
Disposition Summary:
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.
Updated: Tue, 22 Dec 2015 15:08 GMT
Attachments:
- webdds_Annex_A.docx 23 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)
- webdds_rest1_example.json 11 kB (application/json)
- webdds_section_8_3_5.docx 30 kB (application/vnd.openxmlformats-officedocument.wordprocessingml.document)

Web-Enabled DDS — All Issues

Issues Summary

Issues Descriptions

Enhancement to resolution of DDSWEB-3 / DDSWEB-20

Missing HTTP return code for DDS_ERROR

Inconsistent and incomplete specification of resource representations

Correct minor inconsistencies in naming

Use of WebSockets is underspecified

X-Types Dependency

Access Control Relationship with DDS Security

The title of the submission is misleading

Namespace are non aligned with new PSMs

Wrong Acknoledgment

Copyright Violation

The URL prefix of the specification documents is not consistent with the XSD targetNamespace

Qos Profiles and Types are underspecified and inconsistent with XSD

Inconsistent and incomplete specification of resource representations

Missing HTTP return code for DDS_ERROR

Incomplete specification of the GET operation on the DataReader (Section 7.4.8.1)

JSON Missing

Key	Issue	Reported	Fixed	Disposition	Status
DDSWEB-25	Enhancement to resolution of DDSWEB-3 / DDSWEB-20	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-9	Missing HTTP return code for DDS_ERROR	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-14	Inconsistent and incomplete specification of resource representations	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-33	Correct minor inconsistencies in naming	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-30	Use of WebSockets is underspecified	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-8	X-Types Dependency	DDS-WEB 1.0b1	DDS-WEB 1.0	Closed; No Change	closed
DDSWEB-7	Access Control Relationship with DDS Security	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-2	The title of the submission is misleading	DDS-WEB 1.0b1	DDS-WEB 1.0	Closed; No Change	closed
DDSWEB-6	Namespace are non aligned with new PSMs	DDS-WEB 1.0b1	DDS-WEB 1.0	Closed; No Change	closed
DDSWEB-5	Wrong Acknoledgment	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-4	Copyright Violation	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-1	The URL prefix of the specification documents is not consistent with the XSD targetNamespace	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-21	Qos Profiles and Types are underspecified and inconsistent with XSD	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-19	Inconsistent and incomplete specification of resource representations	DDS-WEB 1.0b1	DDS-WEB 1.0	Duplicate or Merged	closed
DDSWEB-17	Missing HTTP return code for DDS_ERROR	DDS-WEB 1.0b1	DDS-WEB 1.0	Duplicate or Merged	closed
DDSWEB-29	Incomplete specification of the GET operation on the DataReader (Section 7.4.8.1)	DDS-WEB 1.0b1	DDS-WEB 1.0	Resolved	closed
DDSWEB-3	JSON Missing	DDS-WEB 1.0b1	DDS-WEB 1.0	Deferred	closed