– DRAFT –
WoT Thing Description

<Ege> w3c/wot#1243

Minutes review

<Ege> https://www.w3.org/2025/10/15-wot-td-minutes.html

ege: Please point out only what you disagree with, typos will be addressed later

<no remarks>

ege: Approved

Binding Templates

PRs

ege: We have few PR approved by non-editors, so we should review them now as well

<Ege> w3c/wot-binding-templates#450

ege: Any remarks?

<none>

ege: Merged

<Ege> w3c/wot-binding-templates#446

<cris> good to go +1

ege: Any remarks?

<none>

ege: Merged

URI vs IRI

<Ege> lb: to sum it up, we reached consensus that we can use URIs. Whoever needs IRI-like strings, they encode

<Ege> ek: correct

ege: We'd have a theoretical breaking change

lb: to sum it up, we reached consensus that we can use URIs. Whoever needs IRI-like strings, they encode

ege: correct

lb: We can also consider it a profile problem, but for 2.0 we can just break and have a clean reference to URI

dape: we have `base` and `href` using different types?

ege: They are both anyURI, the text description is referencing URI, IRI and the URI RFC

dape: We use href in two places, we should make sure we update all the places

cris: Is joining IRIs having the same rules as URI ?

lu: yes

<Ege> https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/

lu: We can break the xml tradition and have strict URI, since we have consensus for it, or we can go the profile way

ege: Profiles would have quite a bit of trouble to restrict that

lu: We can stay with URI and avoid troubles

mahda: Ontologies use IRI, are we fine with restrict? what about jsonschema?

lu: in any case IRI and URL parser would deal with %encoded uri

dape: We should allow non-ascii string

lu: then we do not have consensus?

mn: the Consumers will reject the uri scheme if they don't support it. Like a browser cannot use mailto: and will open email client