Subject: Re: [Asdf] ASDF Digest, Vol 3, Issue 4

From: David Kemp <[email-masked]>
Date: Fri, 14 Aug 2020 10:39:58 -0400

We certainly don't want a namespace URI to change depending on it's
download location!

The issue I see is calling something related to JSON a "default
namespace".  XML data has namespaces, JSON data does not.  Namespacing
applies only to schemas -- a namespace is a unique identifier from which to
obtain type definitions.  An SDF file can assert with confidence "
https://example.com/capability/cap" is my namespace, my unique identifier.

But what does it mean for an SDF file to say "cap is my defaultNamespace"?
Default for what?  Under what circumstances would an SDF namespace be
missing for which a default would need to be supplied?

The purpose of namespacing is to enable independent development of
capabilities, and later, smooth integration of those capabilities.  If two
people from two different organizations develop IoT devices and both think
it would be cool to give their SDF files a defaultNamespace of "cap", what
happens when a third organization tries to use them together?

"cap" might be better understood as an instantiation of "self" - a class
doesn't know it's own identifier until it is instantiated, and different
instantiations have different identifiers.  At the time SDF file A is
written A's author has no idea who will be using namespace A or what short
name they will use to refer to it.

So another way of representing the same information would be:

    "namespace": {
        "default": "https://example.com/capability/cap",
        "zcl": "https://zcl.example.com/sdf"
    }

where "default" (or "self") is a reserved word meaning "this file's
namespace".

If SDF makes a file authoritative for its own short name, it will need to
describe what happens when two organizations pick the same short name
to refer to their respective namespaces.  That can be done, it just seems
unnecessary.

Regards,
Dave

From: David Kemp <[email-masked]>
> Is it reasonable to align SDF with JSON Schema by presenting the same
> information in a clearer way?
>
> <https://www.ietf.org/id/draft-onedm-t2trg-sdf-00.html#section-3.2-5>
>
> "id": "https://example.com/capability/cap",
> "namespace": {
>   "zcl": "https://zcl.example.com/sdf"
> }
>
> <https://www.ietf.org/id/draft-onedm-t2trg-sdf-00.html#section-3.2-6>
>
>
> From: Carsten Bormann <[email-masked]>
>
> Well, the json-schema.org proposals and SDF go into different spaces, so
>> I don’t think there is a strong reason to align.
>
>
>
> More recent versions of the json-schema.org proposals use $id for
>> modifying a “base URI” (which is otherwise inherited from document context
>> as defined in Section 5.1.4 of RFC 3986.  We certainly wouldn’t want a
>> feature that makes the meaning of an SDF spec depend on from where you are
>> downloading it.
>
>
>
> I like the fact that the current structure gives the defaultNamespace a
>> short name as well (“cap” in the example).
>
>
>