要約

  • RFC 9880はネットワークから相互作用できるThingの意味モデルを定義するが、通信方式そのものは定義しない。
  • 名前空間、参照解決、critical feature、sdfRequired、そして明示的なバインディングを別々に検証する必要がある。

SDFのThingは相互作用の対象となるエンティティである。Objectは構造をまとめ、Propertyは読み書きされるデータを表し、Actionは操作を表し、Eventは通知を表す。交換されるデータ型もモデルに含まれる。しかし、URL、数値識別子、ペイロード形式、呼び出し方法、順序、信頼性はモデルから自動的には決まらない。これらはプロトコルバインディングまたは明示的な拡張の責務である。SDFモデルだけではワイヤープロトコルも相互運用性も保証せず、特定のIoTエコシステム、転送方式、シリアライゼーションも強制しない。ベンダーや導入済み製品の対応も、別の一次証拠なしには主張できない。

namespace mapは短い接頭辞をnamespace URIに結び、defaultNamespaceが対象namespaceを選ぶ。既定namespaceがなければ定義はローカルにとどまり、他モデルから再利用できない。外部名にはmapで定義された接頭辞を持つCURIEを使う。SDF名に通常の相対URI解決を適用してはならない。namespace URIやfeature URIを実行時に取得して意味を発見することも要求されない。

sdfRefの解決は前処理の境界である。参照先の定義をコピーし、参照元の定義をJSON Merge Patchとして適用する。入れ子のsdfRefも処理し、nullメンバーで継承内容を削除できる。JSON Pointerは参照先のアドレスを、JSON Merge Patchは統合規則を担う。すべてを展開したものがresolved modelであり、表示上の便利機能ではなく、検証とバインディングの入力である。

featuresは無視できないcritical extensionを示す。sdfRequiredは、どのaffordanceまたはグループを表現しなければならないかを示すが、バインディングがそれを搬送・呼び出しできることまでは意味しない。

基礎SDFのデータ制約と、URL、数値ID、ペイロード、呼び出し、順序、信頼性を分けることがロックインを抑える。暗黙の規則なら、同じresolved modelからでも互換性のないメッセージが生まれる。

出典