Open lu-zero opened 1 year ago
lu-zero
commented
1 year ago The problem is felt by other implementers, the new WoT charter will probably have a registry of extensions a la https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml to avoid implementing json-ld transformations.
Tracking issues: https://github.com/w3c/wot-thing-description/issues/1774 https://github.com/w3c/wot-binding-templates/issues/239
dodomorandi
commented
1 year ago The approach with registries is mostly irrelevant to the issue or worst, only complicates things. The current approach is just a way to avoid the continuous repetition of an Unique Resource Identifier (URI), creating a local mapping to a free short name and then using that name, which could not make sense externally. Using a registry is not just useless (because we already have a way to identify unique resources), but it also complicates thing in more than one way.
For instance, with the needs for a global and official registry, vendors are less likely to embrace the standard, because they not only need to follow something for which maybe they need to rewrite large parts of their codebases, but they will also need to register an official short name for themselves to IANA.
Second problem: this approach cannot just ignore that they decided to use JSON-LD, they still need to correctly use it. Therefore, it is still necessary to perform the mapping as before because with JSON-LD you can assign a prefix to a context given an URI, and this must be still valid. Moreover, now it is also necessary to remotely interact with IANA in order to check the validity of the mapping between URIs and prefixes, which only creates more cases that need to be evaluated: should external crates (or in general libraries) be able to compile if they use a wrong mapping? What about vendors that still need to register their prefix? Should incoming wot-tds with virtually correct structure but wrong (unassigned, misspelled or whatsoever) prefixes be considered invalid? If we need to be lax in practice, this approach only requires to implement more things without solving any issue.
Third problem: if this solution is adopted, the next version of the standard is extremely breaking. If some vendor considered to use WoT because it looked good, they are probably going to really dislike the new constraints, refusing to implement the new version or, even worse, moving to other non standard proposals. WoT is not something already adopted by the industry, and using something overly complex like JSON-LD as base structure is not attracting per se, introducing more and more level of complexity will just make the technology less attractive to industry. There are already a good amount of standard with a very low adoption, please don't make this error again and again.
If the w3 committee really wants to touch this part, and the idea is to solve the situation and not just introducing entropy to the problem, the first thing that must be done is to implement an "extension only" library in any programming language that allows to produce only the custom pieces for a WoT-TD, with a coherent and strict validation system that is able to evaluate and check the mapping between URIs (specified in the extension) and prefixes (as provided by other clients). Once this has been done and only and this point, the critical aspects of the current specification will be more clear.
If I am not wrong, this will highlight that many issues can be related to JSON-LD and the fact that there are an incredible amount of ways to express the same thing. Which means that a reliable validation system is not easy at all. In my humble opinion, the first thing to improve the situation with WoT is to provide better tools, libraries and examples around practical use of JSON-LD. If at that point there is an agreement that the specification is more than clear, it is simple for a vendor to check whether a WoT-TD is valid or not, there is at least one implementation that can correctly handle all the situations, then we can really consider if vendors would appreciate the requirement of a IANA-registered prefix. Considering this last point without the feedback of vendors and without all the prerequisites I expressed feels like adding entropy to the problem hoping for a fix.
A context vocabulary could be added to a Thing using a prefix, right now we use canonical hardcoded prefixes for the extensions, we should be able to allow custom ones.
Problems:
@contextand the extension itself need to be coherent, we need to figure out the least annoying way to enforce it.@contextbefore we can setup the deserializer completely, serde-ignored is able to split the deserialization at runtime, but in our case we'd have to defer it until we know the full mapping by parsing@context.