Replace usages of sdfContext with sdfProperty

Author: JKRhb

draft-ietf-asdf-instance-information.md

@@ -323,9 +323,7 @@ Messages may have to be complemented by this context for
 interpretation, i.e., the context needed may need to be reified in the
 message (compare the use of SenML "n").
 Information that enables interactions via application-layer protocols (such as an IP address) can also be considered context information.
-
-For this purpose, we are using the `sdfContext` keyword introduced by {{-non-affordance}}.
-Note that `sdfContext` *could* also be modelled via `sdfProperty`.
+For this purpose, the `sdfProperty` quality is reused.
 
 TODO: explain how {{RFC9039}} could be used to obtain device names (using `urn:dev:org` in the example).
 
@@ -403,7 +401,6 @@ Note that we also have to replicate a nested structure via `sdfThing` and/or `sd
 | thingId          | string | (Optional) identifier of the instance (e.g., a UUID)                |
 | sdfThing         | map    | Values for the thing entries in the referenced SDF definition       |
 | sdfObject        | map    | Values for the object entries in the referenced SDF definition      |
-| sdfContext       | map    | Values for the context entries in the referenced SDF definition     |
 | sdfProperty      | map    | Values for the properties in the referenced SDF definition          |
 | sdfAction        | map    | Values for the actions in the referenced SDF definition             |
 | sdfEvent         | map    | Values for the events in the referenced SDF definition              |
@@ -427,7 +424,7 @@ Security-related aspects, e.g. regarding authentication and authorization, MUST
 In practical use, we can at least differentiate two use cases for snapshot messages.
 The corresponding message variants are (colloquially) referred to as "Context Snapshots" and "Proofshots".
 
-Context Snapshots *only* contain context information related to a Thing (indicated via the `sdfContext` quality).
+Context Snapshots *only* contain context information related to a Thing (indicated via non-writable `sdfPropety` definitions).
 {{example-context}} gives an example for this kind of instance-related message.
 
 ~~~ sdf
@@ -442,7 +439,7 @@ sdfInstanceOf:
   model: sensors:#/sdfObject/envSensor
 sdfInstance:
   thingId: envSensor:abc123
-  sdfContext:
+  sdfProperty:
     installationInfo:
       floor: 3
       mountType: ceiling
@@ -475,10 +472,9 @@ sdfInstanceOf:
   model: sensors:#/sdfObject/envSensor
 sdfInstance:
   thingId: envSensor:abc123
-  sdfContext:
+  sdfProperty:
     installationInfo:
       mountType: ceiling
-  sdfProperty:
     temperature: 23.124
 
 ~~~
@@ -516,7 +512,7 @@ sdfInstanceOf:
   model: sensors:#/sdfObject/envSensor
 sdfInstance:
   thingId: envSensor:unit42
-  sdfContext:
+  sdfProperty:
     ipAddress: 192.168.1.5
     unit: Cel
     deviceIdentity:
@@ -531,7 +527,7 @@ A special type of construction message that only contains identity-related infor
 
 <!-- TODO: Evaluate whether this approach actually works -->
 Via `sdfRequired`, an SDF model can indicate which context information must be present and therefore initialized within an instance.
-All definitions included in `sdfRequired` MUST also be present in a construction message, while other `sdfContext` definitions could be left out.
+All definitions included in `sdfRequired` MUST also be present in a construction message, while definitions could be left out.
 
 ~~~ sdf
 info:
@@ -544,7 +540,7 @@ sdfInstanceOf:
   model: sensors:#/sdfObject/envSensor
 sdfInstance:
   thingId: envSensor:unit42
-  sdfContext:
+  sdfProperty:
     deviceIdentity:
       manufacturer: HealthTech Inc.
       firmwareVersion: 1.4.3
@@ -604,7 +600,7 @@ sdfInstanceOf:
   model: sensors:#/sdfObject/envSensor
   patchMethod: merge-patch
 sdfInstance:
-  sdfContext:
+  sdfProperty:
     installationInfo:
       mountType: wall
 ~~~
@@ -620,9 +616,11 @@ Other specifications may define additional use cases instance-related messages c
 
 ## Construction
 
-In SDF models, we can speicify a Thing's configurable parameters via `sdfContext` definitions for which Construction Messages can provide concrete values.
+In SDF models, we can specify a Thing's configurable parameters via `sdfProperty` definitions for which Construction Messages can provide concrete values.
 {{code-sdf-construction-sdf-context}} shows an example for such an SDF model.
-The parameters settable during construction (in this case: the `temperature` property's `unit`) are modeled as `sdfContext` definitions, to which the entries of the `sdfParameters` map may point to using JSON pointers.
+In this example, the `unit` quality of the `temperature` property has to be considered a construction parameter, as a connection to the `unit` property is established via the `sdfParameters` map using a JSON Pointer.
+
+If the `unit` is not initialized during construction, it falls back to the default `Cel` for degrees Celcius.
 
 ~~~ sdf
 namespace:
@@ -634,32 +632,33 @@ sdfObject:
     sdfRequired:
       - ipAddress
       - deviceIdentity
-    sdfContext:
+    sdfProperty:
       ipAddress:
+        writable: false
         type: string
       unit:
+        writable: false
         type: string
+        default: Cel
       deviceIdentity:
+        writable: false
         type: object
         properties:
           manufacturer:
             type: string
           firmwareVersion:
             type: string
-    sdfProperty:
       temperature:
         type: number
         sdfParameters:
-          unit: "#/sdfObject/sensor/sdfContext/unit"
-        sdfRequired:
-          - "#/sdfObject/sensor/sdfContext/unit"
+          unit: "#/sdfObject/sensor/sdfProperty/unit"
 ~~~
 {:sdf #code-sdf-construction-sdf-context
 title="Example for SDF model with constructors"}
 
 Based on the SDF model above, a Construction Message such as the one shown in {{code-sdf-construction-message}} can trigger a construction process.
 As indicated via `sdfRequired`, this process must include the initialization of an IP address as well as the device's identity definitions.
-In the example model, initializing the `unit` context definition is only required if the `temperature` property is present, which is expressed by the JSON pointer within the property's `sdfRequired` definition.
+Initializing the `unit` quality is only required if the `temperature` property is present, which is expressed by the JSON pointer within the property's `sdfRequired` definition.
 
 ## Protocol Binding Information
 
@@ -671,7 +670,7 @@ Therefore, we can utilize context information that varies between instances to c
 
 {{code-sdf-protocol-map-plus-context}} illustrates the potential relationship between the two concepts in an SDF model.
 Here, a (hypothetical) CoAP protocol mapping specification defines an interface for parameters such as an IP address.
-Via JSON pointers, the `sdfParameters` within the `sdfProtocolMap` are linked to compatible `sdfContext` entries that may further restrict the set of allowed values via their schema definitions.
+Via JSON pointers, the `sdfParameters` within the `sdfProtocolMap` are linked to compatible `sdfProperty` definitions that may further restrict the set of allowed values via their schema.
 
 ~~~ sdf
 namespace:
@@ -680,16 +679,18 @@ namespace:
 defaultNamespace: models
 sdfObject:
   sensor:
-    sdfContext:
+    sdfRequired:
+      - ipAddress
+    sdfProperty:
       ipAddress:
+        writable: false
         type: string
-    sdfProperty:
       temperature:
         type: number
         sdfProtocolMap:
           coap:
             sdfParameters:
-              ipAddress: "#/sdfObject/sensor/sdfContext/ipAddress"
+              ipAddress: "#/sdfObject/sensor/sdfProperty/ipAddress"
             read:
               method: GET
               href: "/temperature"
@@ -698,7 +699,7 @@ sdfObject:
 {:sdf #code-sdf-protocol-map-plus-context
 title="Example of an SDF model where a CoAP-based protocol map points to the definition of relevant context information: an IP address."}
 
-{{code-sdf-ipaddress-context}} shows how a Snapshot Message can provide the necessary IP address that is needed for retrieving the temperature value from the sensor described by the SDF model above.
+{{code-sdf-ipaddress-context}} shows how a Snapshot Message can report the necessary IP address that is needed for retrieving the temperature value from the sensor described by the SDF model above.
 
 ~~~ sdf
 info:
@@ -710,18 +711,18 @@ defaultNamespace: models
 sdfInstanceOf:
   model: sensors:#/sdfObject/sensor
 sdfInstance:
-  sdfContext:
+  sdfProperty:
     ipAddress: 192.168.1.5
 ~~~
 {:sdf #code-sdf-ipaddress-context
 title="Example of a snapshot message that provides the IP address needed to perform a CoAP-based interaction with the sensor from the previous figure."}
 
 ## Modelling the State of Interaction Affordances
 
-Besides context information, Snapshot and (in a relative fashion) Delta Messages can report the current state associated with interaction affordances.
-For `sdfProperty` definitions, this is very similar to context information and very straightforward, as previously seen in in {{code-sdf-delta-message}}.
+Snapshot and (in a relative fashion) Delta Messages can report the current state associated with interaction affordances.
+For `sdfProperty` definitions, this is very straightforward, as previously seen in in {{code-sdf-delta-message}}.
 
-Actions and events, however, are handled differently: In the case of actions, the state of one or more actions is reported, which might already be in a completed or error state, or may also still be running.
+Actions and events, however, need to be handled differently: In the case of actions, the state of one or more actions is reported, which might already be in a completed or error state, or may also still be running.
 For events, a history is reported that includes the returned values.
 The exact of number of action and event reports is implementation-dependent and may vary between deployments.
 
@@ -803,13 +804,17 @@ namespace:
 defaultNamespace: models
 sdfObject:
   envSensor:
-    sdfContext:
+    sdfProperty:
       deviceIdentity:
-        manufacturer:
-          type: string
-        firmwareVersion:
-          type: string
+        writable: false
+        type: object
+        properties:
+          manufacturer:
+            type: string
+          firmwareVersion:
+            type: string
       installationInfo:
+        writable: false
         type: object
         properties:
           floor:
@@ -818,11 +823,9 @@ sdfObject:
             enum:
             - ceiling
             - wall
-    sdfProperty:
       temperature:
         type: number
         unit: Cel
-
 ~~~
 {:sdf #code-off-device-model
 title="SDF Model that serves as a reference point for the instance-related messages in this draft"}