CORE and TRANSPORT spec minor updates. #442
Conversation
| @@ -182,7 +182,7 @@ <h2>Definitions</h2> | |||
| <dl title="enum Defs" class="idl"> | |||
| <dt><b>client</b></dt> | |||
| <dd>An entity that works with data managed by a server.</dd> | |||
| <dt><dfn data-dfn-type="dfn" id="dfn-server">server</dfn></dt> | |||
| <dt><b>server</b></dt> | |||
There was a problem hiding this comment.
The bug is here, because there is no link from any word to the word in the doc. But I think it is better to keep this id for server word. I am going to fix it with making a link to this word.
| The format of these number strings MUST follow the number formats as specified in [[RFC8259]]. | ||
| A single data point is in the message payload represented by a value and an associated timestamp, | ||
| in JSON represented by two key-value pairs with the key names "value" and "ts".<br> | ||
| The "ts" value MUST be a string as specified in <a href="#timestamp"></a>, while the "value" value MUST be a string, |
There was a problem hiding this comment.
'while the "value" value MUST be a string,' ==> might be remove value, because there are two times of value.
There was a problem hiding this comment.
It becomes a bit tricky to talk about the value component in a key-value pair when the key is named value:).
Even if "value" value may look strange, I think it is less confusing than removing value.
So I keep it unless there is strong opposition;).
| @@ -317,8 +324,8 @@ <h2>Methods</h2> | |||
| and MAY implement the Subscribe, Unsubscribe, and Subscription methods. | |||
| </p> | |||
| <section id="read"> | |||
| <h2><dfn>Read</dfn></h2> | |||
| <p><a>Purpose</a>: Get one or more values addressed by the given path.</p> | |||
| <h2>Read</h2> | |||
There was a problem hiding this comment.
This is the same issue with "server" previously. I am going to fix it.
| <h2><dfn>Update</dfn></h2> | ||
| <p><a>Purpose</a>: Provide altered value to the vehicle signal(s) addressed by the <a>path</a></p> | ||
| <p>The client MAY have to obtain an authorization token before being able to update the vehicle signal(s). | ||
| <h2>Update</h2> |
There was a problem hiding this comment.
This is the same issue with "server" previously. I am going to fix it.
| @@ -366,8 +373,8 @@ <h2><dfn>Update</dfn></h2> | |||
| </section> | |||
|
|
|||
| <section id="subscribe"> | |||
| <h2><dfn>Subscribe</dfn></h2> | |||
| <p><a>Purpose</a>: Get asynchronous messages containing the value(s) addressed by the path. | |||
| <h2>Subscribe</h2> | |||
There was a problem hiding this comment.
This is the same issue with "server" previously. I am going to fix it.
| @@ -389,8 +396,8 @@ <h2><dfn>Subscribe</dfn></h2> | |||
| </p> | |||
| </section> | |||
| <section id="unsubscribe"> | |||
| <h2><dfn>Unsubscribe</dfn></h2> | |||
| <p><a>Purpose</a>: Termination of the subscription period started by a previous subscribe request.</p> | |||
| <h2>Unsubscribe</h2> | |||
There was a problem hiding this comment.
This is the same issue with "server" previously. I am going to fix it.
| @@ -407,8 +414,8 @@ <h2><dfn>Unsubscribe</dfn></h2> | |||
| </p> | |||
| </section> | |||
| <section id="subscription"> | |||
| <h2><dfn>Subscription</dfn></h2> | |||
| <p><a>Purpose</a>: Asynchronous client notification according to the subscribe request trigger rules.</p> | |||
| <h2>Subscription</h2> | |||
There was a problem hiding this comment.
This is the same issue with "server" previously. I am going to fix it.
| @@ -1476,12 +1479,12 @@ <h2>Term Definitions</h2> | |||
| <td>A JWT formatted security token.</td> | |||
| </tr> | |||
| <tr> | |||
| <td><dfn data-dfn-type="dfn" id="dfn-data">data</dfn> </td> | |||
| <td><b>data</b> </td> | |||
There was a problem hiding this comment.
This is the same issue with "server" previously. I am going to fix it.
| <td>object/array</td> | ||
| <td>Contains a path and one or more data points.</td> | ||
| </tr> | ||
| <tr> | ||
| <td><dfn data-dfn-type="dfn" id="dfn-dp">dp</dfn> </td> | ||
| <td><b>dp</b> </td> |
There was a problem hiding this comment.
This is the same issue with "server" previously. I am going to fix it.
| @@ -1501,7 +1504,7 @@ <h2>Term Definitions</h2> | |||
| <td>Provides a filtering mechanism to reduce the demands of a subscription on the server. Query format, see CORE:Filter Request.</td> | |||
| </tr> | |||
| <tr> | |||
| <td> <dfn data-dfn-type="dfn" id="dfn-metadata">metadata</dfn> </td> | |||
| <td> <b>metadata</b> </td> | |||
There was a problem hiding this comment.
This is the same issue with "server" previously. I am going to fix it.
| describes the VISSv2 messaging layer. | ||
| The companion specifications for the VISSv2 transport protocols detail the mapping of the messaging layer to selected transports. | ||
| The companion specification for the VISSv2 transport protocols detail the mapping of the messaging layer to selected transports. | ||
| The ontologies based on the VISSv2 core specification are defined in documents for each specific domain |
There was a problem hiding this comment.
The row on ontologies has not been changed by this PR, but out of curiosity - which documents do we refer to here?
There was a problem hiding this comment.
I guess it is the VSSo documents that Daniel is about to publish?
spec/VISSv2_Transport.html
Outdated
| @@ -1029,15 +1028,17 @@ <h2>Subscribe</h2> | |||
| The client may send a <a href="#dfn-subscriberequest" class="internalDFN" data-link-type="dfn">subscribeRequest</a> message | |||
| to request a subscription to one or more signals, | |||
| thereby requesting the server to repeatedly return subscription notification messages, as specified by the "filter" query | |||
| (see CORE, "Filtering" chapter). | |||
| (see [[viss2-core]], Filtering chapter). | |||
| The server <em class="rfc2119" title="MAY">MAY</em> reduce the number of | |||
| <a href="#dfn-subscriptionnotification" class="internalDFN" data-link-type="dfn">subcriptionNotification</a> | |||
| messages sent to the client in order to reduce processing demands.<br> | |||
| If the server is able to satisfy the request it SHALL return a | |||
| <a href="#dfn-subscribesuccessresponse" class="internalDFN" data-link-type="dfn">subscribeSuccessResponse</a> message. | |||
| If an error occurs e.g. because the client is not authorized to set the requested value, the server SHALL return a | |||
There was a problem hiding this comment.
Shall it be "not authorized to read" rather than "not authorized to set". For subscriptions the ability to "set" should not matter, or?
There was a problem hiding this comment.
You are absolutely right. I will update.
No description provided.