Meeting minutes
agenda
Luca: should we start the discussion about degraded consumption
Ege: if there is time I want to talk about the data mapping
… the idea is to use the Plug Fest for degraded consumption to get more experience
Registry Requirements
<kaz> wot-binding-templates PR 378 - Registry Requirements Update
Ege: For this I have started a little PR for this
… there was a point about the breakout session
… there is then DISCUSS for open points in the bindings
… identification of bindings to be discussed. There were two text written "this alternative seems to have more consensus". I want to ask you how should the identification happen in general. Whether there should be new terms, or subprotocols
… is there any further remarks from your side?
(none)
… whether the URI scheme should be regisitered in IANA first, Cristiano mentioned last time that we should do provisional registration. This brings additional work.
… what do you think, do you think we should mandate the URI scheme?
Luca: even if it might have overhead, it should be required that anything we put is already IANA registeres, at least provisional registration. Once the whole thing is completed we should have both the schema and the media type present in IANA so we don't have duplication
Ege: so you are for having it first registered in IANA?
Luca: yes, for people who want to do that it might be additional work but for the people who are involved would be less work
Ege: do you say at least provisional?
Luca: what happens is that IANA lets you use the x- prefix, if we accept provisional protocols they can use that as the media type. But once we decide to set in stone, the protocol must also be registered in IANA. The downstream can use the information registered in IANA to deal with that. Implementation wise there is already something that can be
leveraged
Ege: somebody is going to submit a binding, do we say no if it is not submitted or?
Luca: The life cycle of the submission can be: somebody wants to have their own stuff as protocol binding, in order to do that, we will say we will give you feedback.
… but once we decide that this is good to go, the person has to do the process of registering the scheme in IANA. It isn't possible that our registry shows something and IANA shows something else, otherwise we will have a problem
<kaz> Preview
Daniel: once we merge it, it should be not only provisoned with a x-, it should be final. But beforehand, once someone wants to contribute a binding, it's not worth it that they submit the media type. We should put a process here. You can propose a media type or a scheme, but we won't merge it until it's not a final definite IANA, and not just a
… temporary one. I do not want to get people to work if it is tempoerary
Ege: we don't have to have this rule, but all the other registries do not allow updating an entity, it cannot be a work in progress in a registry, if we follow this rule it should go through a lifecycle that needs to be defined
Kaz: why don't we start with the content of registry definition a bit more before diving into how to deal with that
Ege: we will also come to that later
Kaz: my point is that the order of the discussion point, the content of the registry entry should be the first to discuss
… we should clarify what kind of URI schema and media type for which binding and ecosystem and so on
Ege: so far the URI schema was mandated ...
Kaz: I understand the history of WoT itself, we should clarify the need for the template and the items, and then we can follow this kind of detailed the discussion. I'm not objecting to discuss about these topics as well. The order of the discussion is strange for me.
Ege: ok, lets first with the rules of registry first
(Ege does some changes in the registry0requirements file)
Kaz: maybe the current expectation can be changed to basic requirements
Ege: in the registry we need to define two things, what is submitted and what is in the table, and the text around it. This is called the registry definition
<kaz> WebCodecs Codec Registry (as an example registry)
Ege: Ege shows an example
… we have to agree on 3 things, what is the registry, what kind of content do we expect, and what are the requirements (this is what we are discussing at the moment)
… the basic requirements are what we discuss and the entry requirement is what the submitters see
… I think there will be a need for reorganization in the document
… we should start with the properties that we need in that example table
… (Ege performs some changes in the document)
… if somebody goes in the binding template document, it seems that our tables are not aligned
… it is a good idea to avoid prefix coliisioN
… what do you think?
… what do you imagine seeing in this kind of table?
Kaz: once we as the WoT TD TF have clarified our basic requirements for binding template registry and have got approval by the whole WoT WG, we can bring our idea to PLH as the strategy lead and W3C registry contact about possible registry document for WoT Binding Template. In any case we need to get approval for publication of the registry . Talking with him beforehand would be good.
Ege: right. if we want to avoid collision on the ontology prefix, we have to also avoid collision on the URI schema and media types, therefore they should also be listed
… this is sort of overlap with the identification discussion, the way we identify should be sort of in the table
… (Ege does some changes in the document, section Entry format)
… other opinions on what this table should contain?
(none)
… let me commit this file
<kaz> Updated preview
Ege: I will work on this document as there needs to be some improvements and enable more discussions
Data Mapping
<Ege> TD.Next Usability and Design Work Items - Data Schema Mapping
Ege: this was a topic that was discussed in multiple places and is actually part of the discussion in the following document
… I will just do an intro and we can have some initial discussion
… what we have as a topic is that we want to have the TD as a schema part and we bind it to the actual request. However, we have some discrepancy, the URI variables.
… bring dataschema to the specific protocol parameters
… the second point is that in case of some protocols, we have to find a way to map to their specific content type, they have bits and bytes. We have to find a way to go from json schema, currently this is loosely represented.
… this was also mentioned by Jan, to have more expressivness in our DataSchema
… Luca has provided some ideas on URI variables for BACnet
<Ege> wot-thing-description Issue 1936 - Supporting complex/structured types in simple protocols
Ege: this is one concrete use case in a modbus device, we will bring it in the plug fest to see the real problem
<kaz> Kazeem's comment including an example TD
Ege: Kazeem from Siemens also provided a discussion, each bit inside the byte have different meanings
… in the next case, we have a property which is an object, that is mapped to the form part in the TD, the implementation behind has to translate the abstract stuff to concrete protocol information.
Ege: do people need more examples on this case?
(none)
Kaz: This clarification would be useful, but what would really happen for each ecosystem and protocol? Should this approach applied to any kind of ecosystem with a TD?
Ege: It can be also applied
Kaz: we need more concrete use cases
Ege: do you mean categoizing them?
Kaz: I am not sure about categorization itself at the moment, but we need more survey and research on each ecosystem and protocol one by one for this approach
Ege: I can provide more details
Ege opens up an issue
… I think we can deal with this issue in a similar way to the initial discussion topic, anyone who has experience on it can provide examples
w3c/
… looking at the WoT TD project, we wait for Jan and Michael Koster for the binding issues
Project and Backlog
Ege: Any other topics to discuss quickly?
(none)
<kaz> [adjourned]