Question is id in 7.2.2.1.1 the same as TD id?

[aphillips]

7.2.2.1.1 Creation
https://w3c.github.io/wot-discovery/#exploration-directory-api-things-creation

A TD that has an id MUST be submitted to the directory in the body of an HTTP PUT request at /things/{id} endpoint, where id is the unique TD identifier, present inside the TD object. An Anonymous TD is handled differently; see below. The request SHOULD contain application/td+json Content-Type header for JSON serialization of TD. The TD object is validated in accordance with 7.2.2.1.6 Validation. Upon successful processing, the server MUST respond with 201 (Created) status.

WOT-Description says that the id is of type anyURI, but here the id is inserted as a path element. This suggests that the id is more of a name token (a URI would have its URI syntactical bits URL-encoded, right?). I'm trying to gauge where non-ASCII can get in here and if so how it will be represented?

[mmccool]

It is the same as the TD id, and you make a good point that we may have to do some encoding if it is a URI.

[mmccool]

Related somewhat to issue #382 and URL-encoding of ids. I expect we can resolve both these issues together.

[aphillips]

@mmccool noted in w3c/i18n-activity/#1524:

Yes, they are the same. If the TD has no id (it is anonymous) than one is generated. To address the concern you raised (if ids are URL and we use them in a path there may be special character conflicts) we have added assertions to

• Indicate that URL-encoding must be used to escape special characters allowing the id to be embedded in a path
• Indicate that when ids are generated for anonymous TDs, UUIDv4 should be used.

URL-encoding is good for the wire, but not good for humans. Generally this is the difference between RFC3986 (URI) and URL/RFC3987 (IRI). The text should be clear about which form is used where.

When id is considered as a standalone value, note that anyURI's value space is that of IRI (so non-ASCII is permitted and is not escaped). (Look specifically here in XMLSchema) So you were already in pretty good shape with regard to non-ASCII handling.

My concern was: if id is a URI, how does it fit with an HTTP PUT at things/{id}, e.g. wouldn't that make an id of https://example.com/foo into the path /things/https://example.com/foo? Wouldn't you be better off with an NMTOKEN type that is then escaped in paths?

[mmccool]

When the ID is used in the path it is URL-encoded to avoid special characters. For example, the above would show up as /things/https%3A%2F%2Fexample.com%2Ffoo. Yes, this is not especially human-readable but this is an API meant to be used by computers, not to support nice human-readable URLs directly.

The current text specifies that URL encoding is to be used. With that, @aphillips, can we consider this resolved?

[aphillips]

That resolves my question, so I think you can mark this issue as addressed.

[mmccool]

Confirmed resolved. Percent-escaping works to resolve this.