Recent changes to ieee11073-20701

#75 wsd:Scope can not reflect multiple MDSs (and/or VMDs) with the same type

2026-03-16T10:39:06.119000Z

Description has changed:

Diff:

--- old
+++ new
@@ -1,4 +1,4 @@
 Due to section &#34;9.2 Complex Device Component Based Discovery&#34; of SDC Glue in combination with biceps R0134 an SDC SERVICE PROVIDER SHOULD include a URI-encoded pm:AbstractComplexDeviceComponentDescriptor/pm:Type within the scope of the MDPWS discovery
 messages.

-Since the WS-Discovery scope is an &#34;Unordered set of Scopes ... If included, MUST be a set of absolute URIs ...&#34;, this can not reflect mutliple MDSs (and/or VMDs) which have the same type.
+Since the WS-Discovery scope is an &#34;Unordered set of Scopes ... If included, MUST be a set of absolute URIs ...&#34;, this can not reflect multiple MDSs (and/or VMDs) which have the same type.

#75 wsd:Scope can not reflect multiple MDSs (and/or VMDs) with the same type

2026-03-16T10:32:51.659000Z

Description has changed:

Diff:

--- old
+++ new
@@ -1,4 +1,4 @@
 Due to section &#34;9.2 Complex Device Component Based Discovery&#34; of SDC Glue in combination with biceps R0134 an SDC SERVICE PROVIDER SHOULD include a URI-encoded pm:AbstractComplexDeviceComponentDescriptor/pm:Type within the scope of the MDPWS discovery
 messages.

-Since the WS-Discovery scope is an &#34;Unordered set of Scopes ... If included, MUST be a set of absolute URIs ...&#34;, this can not reflect mutliples MDSs (and/or VMDs) which have the same type.
+Since the WS-Discovery scope is an &#34;Unordered set of Scopes ... If included, MUST be a set of absolute URIs ...&#34;, this can not reflect mutliple MDSs (and/or VMDs) which have the same type.

wsd:Scope can not reflect multiple MDSs (and/or VMDs) with the same type

2026-03-16T09:28:00.243000Z

Due to section "9.2 Complex Device Component Based Discovery" of SDC Glue in combination with biceps R0134 an SDC SERVICE PROVIDER SHOULD include a URI-encoded pm:AbstractComplexDeviceComponentDescriptor/pm:Type within the scope of the MDPWS discovery
messages.

Since the WS-Discovery scope is an "Unordered set of Scopes ... If included, MUST be a set of absolute URIs ...", this can not reflect mutliples MDSs (and/or VMDs) which have the same type.

wsd:Scope can not reflect multiple MDSs (and/or VMDs) with the same type

2026-03-16T09:28:00.243000Z

Ticket 75 has been modified: wsd:Scope can not reflect multiple MDSs (and/or VMDs) with the same type
Edited By: Lukas Deichmann (ldeichmann)
Description updated:
--- description-old

+++ description-new

@@ -1,4 +1,4 @@

-Since the WS-Discovery scope is an "Unordered set of Scopes ... If included, MUST be a set of absolute URIs ...", this can not reflect mutliples MDSs (and/or VMDs) which have the same type.
+Since the WS-Discovery scope is an "Unordered set of Scopes ... If included, MUST be a set of absolute URIs ...", this can not reflect mutliple MDSs (and/or VMDs) which have the same type.

wsd:Scope can not reflect multiple MDSs (and/or VMDs) with the same type

2026-03-16T09:28:00.243000Z

Ticket 75 has been modified: wsd:Scope can not reflect multiple MDSs (and/or VMDs) with the same type
Edited By: Lukas Deichmann (ldeichmann)
Description updated:
--- description-old

+++ description-new

@@ -1,4 +1,4 @@

-Since the WS-Discovery scope is an "Unordered set of Scopes ... If included, MUST be a set of absolute URIs ...", this can not reflect mutliple MDSs (and/or VMDs) which have the same type.
+Since the WS-Discovery scope is an "Unordered set of Scopes ... If included, MUST be a set of absolute URIs ...", this can not reflect multiple MDSs (and/or VMDs) which have the same type.

Consider translations for scope matching

2026-03-16T08:10:57.300000Z

According to https://sourceforge.net/p/opensdc/ieee11073-20701/66/ an appropriate Matching Algorithm for SDC Glue should also take the translation of a coded value into account.

Section "9.2 Complex Device Component Based Discovery" provides with NOTE 5 a recommendation to add translations to the scope. Wouldn't the translation be sufficient, especially if the regular Code is from the private partition?

#73 Add subscription-scoped running number to AbstractReports

2026-03-02T09:43:39.975000Z

Ticket moved from /p/opensdc/ieee11073-10207/408/

9.2 dpws:Scope does not exist

2025-10-14T11:38:57.758000Z

The requirement in 9.2 is stating that encoded types are to be added to the dpws:Scope of MDPWS Discovery messages. No such thing exists, this likely is supposed to be the WS-Discovery Scope wsd:Scope. Also the prefix for WS-Discovery wsd needs to be added to 4.1 XML schema namespaces.

#35 Clause 7.4.1 / Removable sub-systems

2025-08-29T12:27:48.710000Z

As a related note that could be solved by the generalization: We should also really get rid of the term "history", as it leaves too much room for interpretation, and enforce this to be consecutive mdib versions. As of now, I can do the first step at some point and undo it and then do the second step, possibly even hours later. The history still contains the sequence of the requested changes, it just isn't working as intended.

R0005: retrievability for context service

2023-03-08T14:08:45.164000Z

This requirement does not cover elements that are retrievable via the CONTEXT SERVICE (retrievability for context service is undefined). Moreover, CONTAINMENT TREE ENTRY is too abstract to be applicable in this context.

Proposal:
R0005: An SDC SERVICE PROVIDER SHALL include msg:Retrievability with @Method ∈ { Per, Ep, Strm } as ext:Extension elements in all descriptors for their states according to the following definition of @Method:

Per: States that are retrievable by periodic reports, i.e. msg:PeriodicAlertReport, msg:PeriodicComponentReport, msg:PeriodicContextReport, msg:PeriodicMetricReport, and msg:PeriodicOperationalStateReport
Ep: States that are retrievable by episodic reports, i.e. msg:EpisodicAlertReport, msg:EpisodicComponentReport, msg:EpisodicContextReport, msg:EpisodicMetricReport, and msg:EpisodicOperationalStateReport
Strm: States that are retrievable by stream reports, i.e. msg:WaveformStream, msg:ObservedValueStream