Meeting minutes
Minutes Review
<kaz> June-14
Ege: We will review the minutes today, but in the future we will review them asynchronously (as described in a policy proposal)
… with the new process, people can suggest amendments via email
… (goes over last time's minutes)
… we will talk about project management via GitHub again today
… (notices an incorrect placement of a link)
… Kaz, could you fix that?
Kaz: Is fixed now
Ege: Does anybody see anything they want to be changed?
… and also, Kaz, for the minutes before that one, we only need to change the names
<Ege> https://
Ege: "minutes" and "minutes review" also need to be merged into one section
Kaz: I think the result from June 14 was not really productive, given that meeting was expected to concentrate on the preparation for the planning meeting...
Ege: Anything more to change?
No change requests, minutes are approved
TPAC
<kaz> TPAC agenda wiki
Ege: You can add your topics to the list in the Wiki
… as discussed in the main call, the JSON-LD-related topics are now in their own section
… also, we had some discussion with the JSON-LD people and we want to discuss the topic of a single source of truth at TPAC
Kaz: As mentioned during the main call, I do not understand why we need to have a breakout session regarding that topic
… this important discussion should not be held in a breakout session
… we need to discuss with them common problems that impact all JSON-LD-based specifitions like namespace handling
… we should discuss these topics with all affected working groups during the official WoT session.
… as this very important for future specifications
Ege: I do not agree with you, but we can discuss it next week at the main call
Sebastian: I don't understand your point here, Kaz, I am very happy that Ege took the initiative to talk to the JSON-LD people. As Ege mentioned, there is a high interest in the JSON-LD working group to make progress on this topic
Kaz: In that case, you should split the discussion into a JSON Schema and a JSON LD part, and provide more background. We should discuss what should be discussed during this Thing Description call first
Ege: This was indeed just a general proposal, we can move on to the TD topics
Kaz: As mentioned during the main call, I don't object to the idea, but we need to clarify what the core topic is and how the stakeholders can be involved
… we need to clear in order not to confuse people and to use these two sessions productively
Ege: JSON-LD-related topics in the Wiki were mentioned under "TD" before, they have now become their own section
Ege: if you want to add something to the list, you can use the link above
PRs
Ege: We can now move on to the PRs
PR 1844
<Ege> PR 1844 - Update schema to not allow empty op array
Ege: We can start with this one as it is the most recent one
… this one only updates the JSON Schema
… before we had a bug that allowed an empty array as a value for the "op" field in a form
… this is addressed by the PR by adding "minItems" members to the respective places in the JSON Schema
Daniel: This is more of a question: Is this change also correct for the Thing Model?
… as it does not need to be fully valid there
Ege: I guess this could make sense as you could fill the array when instantiating the TD
Cristiano: I would be against allowing an empty array for TMs, since you can simply omit the array in that case
… one thing I was wondering about when you opened the issue: What if people what to use the empty array to indicate the default value?
… I don't know how people interpret that
… to me it would be clear that the default should only be used if the value is undefined but maybe it should be explained better in the future
Ege: I think we have it in the SHACL file via a minimum of one element
Cristiano: Maybe this is another source of confusion
Luca: We have other places where you can have a single value or an array of values
… in some cases this might be wasteful
… we should probably be more careful here in the future
Ege: (Adds a comment with a summary of the discussion to the PR)
Luca: The part that is annoying is that implementors need to consider many different cases. We should have a consistent behavior across all fields that are expected to behave in a similar way
Ege: What you mentioned last time regarding "items" is something that definitely needs to be fixed in the next version
Ege: the current version of JSON Schema splits the ArraySchema into two variants
In the discussion, it becomes clear that the semantics and usage of empty arrays must be clarified
Ege: I will propose to not merge this today and to clarify this
… just regarding the op value: Does anybody think that we should allow empty arrays?
Cristiano: For me it is better to only go with the default if you have undefined
Luca: My interpretation would be that you would only use the default value if the value is missing and not if the value is empty
Ege: I agree, I am not sure if that is clear enough in the spec yet, though
… (amends his comment to the PR)
… I will have look until next week, this change would not break any tests I have conducted yet
Kaz: Does this imply that we need to update the spec as well?
Ege: I think some aspects are a bit vague, but we are not in the wrong
Kaz: In that case we should also update the specification, probably not 1.1 but 2.0 in order to improve the document and avoid any kind of confusion
Ege: Changes like these would be editorial, is that okay?
Kaz: Elements like Schema are only resources to help with the understanding of the text
… however, we should think about potential improvements for the next specification version
Ege: The corresponding issue will not be closed
PR 1842
<kaz> PR 1842 - Data schema clarification
Ege: In this PR, Luca simply adds a clarification that JSON Schema 7 is being used
… and processors implementing it can be used
… would that be fine, kaz?
Kaz: The question is simply if this change would impact normative features and implementations.
Koster: I am wondering if we should simply state that we use a subset of JSON Schema Version 7
… and that would indicate to implementors that they can set their ajv accordingly
Luca: In the current wording it might be a bit confusing for implementors since the IETF draft does not tell you that you can use Draft 7 as a package
… persons that are not familiar with JSON Schema can figure out how layered JSON Schema is and do not need to reinvent the wheel. In this proposal I am simply clarifying the intended purpose of this sentence and data schema, without making a normative change
Ege: I agree that this has not been very clear for implementors, if we could add some like this it would be very benefitial
Koster: So you are saying that people should use a particular processor and not that we are using a vocabulary based on Version 7
Ege: Would it be okay to add this, kaz?
Kaz: It is not really recommended to add changes at this stage. We could add it to the Recommendation publication later, but we should not make any unnecessary changes at this point given we had already got the WG resolution for Proposed REC publication and are publishing the spec shortly.
Ege: I think it would be benefitial, as the old statement confused implementors like Luca
Luca: Making this clearer can save a lot of headache
Koster: First version of implementors regarding JSON Schema is always "Which version?", so this would make things easier
Kaz: I am about to publish the Proposed Recommendation, so we cannot add it to the main document now
… we could add it to the Recommendation in one month if it is really necessary
Koster: I would consider it a bug fix
Kaz: We could still add minor editorial changes and bug fixes to the Recommendation
Koster: We could also add a Implementation Guidance section with statements like this
Ege: Should be considered for TD version 2.0
Kaz: There are multiple options, but we could add this minor fix for the Recommendation next month. But we need a WG-wide resolution for that
… we can keep the issue and PR open and add a label
Planning for new Charter
Ege: (starts to describe what is listed on the agenda wiki)
Kaz: you want to describe the policy for the next Charter work. right?
Ege: yes
Kaz: Two comments here
… Firstly, this proposal to be put on GitHub as the basis of the discussion
… Then secondly, the first point here "New features (keywords or behavior) need use case (or user story) justification." sounds a bit strange to me
… It's rather that we should have use cases based on the need from the industry as the basis, then extract requirements from the use cases, and then define necessary features for the WoT specs based on the requirements.
Ege: ok
Cristiano: question about tooling
Ege: we can work on bug fixes and so on
… mainly maintenance, but could work on development of new tooling
Daniel: clarification question
… we do have some features already planned to be added for the 2.0 spec
… do we need use case descriptions for them too?
Ege: my initial feeling is
… good numbers of items are already there
… but would say if the description is not enough, or the discussion so far is not clear yet, would be better to have use case descriptions
… need more discussion, though
Koster: really don't want to have much work unless we have concrete use cases
… some proposals don't really have actual use case descriptions
… some of them might be obvious, though
… maybe still could have some brief description about why needed
Ege: yes, we should dig into concrete use cases for the proposed features
Koster: yeah
… e.g., for the binding templates features, use cases are useful to describe why need what
Kaz: agree
… for minor editorial changes/fixes, maybe no use case needed
… but all the feature additions/improvements should require use case descriptions
… if someone thinks some feature, which has been already raised, is really important, that person should raise a new issue based on concrete use case description
Ege: ok
… would like to move forward for "Big Tasks List Proposal" section then
Koster: (describes the items)
… first two are basic restructuring
* Restructure TD document, e.g. grouping of normative requirements * Restructure TD for usability e.g. common definitions section
Koster: may end up with some markdown language to clarify the points
… high-level categorization of the work items
… starting with a set of summarized aggregations
… both are for usability
… then ThingModel integration into TD doc
… then Protocol Binding integration into TD doc
… to me, a lot of stuff like Luca's document to be included here
… how to put metadata payload, etc.
… would call it refining the binding mechanism
… then registry issue
… three separate pieces to work on
… and then security refactor and spec generation
… how to manage the work and the mechanics would be the question
… is this sort of discussion to be done?
Kaz: agree
… we should go for this direction, and continue the discussion based on this list
Koster: what about other topics?
Ege: restructuring have two items here
Koster: can be put into one category
Koster: not adding any features or anything, but restructure the document
Kaz: agree
… during the restructuring work, we should not add new features :)
Koster: agree with that
… on the other hand, we should work on basic design as well
… moving on architecture, moving on implementations, ...
… we'll be working on many on the architecture
Kaz: right
… and here we don't necessarily mean "WoT Architecture" by "architecture"
… but mean "basic design for binding in general". right?
Koster: right
Ege: for the spec itself
… we should not add new features while working on the big refactoring
… but some concern that the discussion might be going to be a bit boring
… maybe need some different place to manage new feature proposals
Koster: how to deal with the high-level design document?
… let us keep track on high-level design
Kaz: regarding the new feature generation concern, we should restart the Use Cases work asap
… and use that as the basis for all the specs
Ege: for example, we have time-series data as a new proposal
… so far, the Testing TF has been working for Testing for all the specs
… but that's too hard
Ege: as one of the big tasks?
… TD TF should be responsible to testing for TD spec
Ege: ok
Daniel: regarding the use case discussion
… good to restart the work
… in some cases, some of the new features are dependent on a specific spec only
Koster: agree with what Kaz said
… would add categories and labels to use cases/requirements to clarify which ones are for which specs
Kaz: Technically, we as the WoT WG should work on one consolidated Use Cases document which include all the required use cases for WoT in general.
… Then we should extract requirements from the use cases.
… Then we should define necessary technical features for the WoT specs based on the requirements.
… Sometimes we might get requirements for the other related specs, e.g., DID, VC, JSON-LD or video streaming, but we could transfer those requirements to the related WGs rather than improving the WoT standards for that purpose.
Ege: agree
Next discussion topics
Ege: would like to see those two topics too
* Explain what this is: We want to log big discussion topics and invite specific people to the call where that discussion happens. * URI and href design for all protocols (latest issue: https://github.com/w3c/wot-thing-description/issues/1834)
Kaz: You mentioned two items above, but you're actually suggesting we clarify the discussion topics beforehand for the next calls in general. right?
Ege: right
Kaz: should concentrate on the refactoring discussion as the basis for the next charter work
… rather than starting new technical items at this stage
Koster: that makes sense
… need to think about the balance between the refactoring/bug fixes and new tech discussion
… how to use the remaining 6 weeks?
Ege: think it would be better to have some discussion on new features as well, e.g., 30 mins
Koster: would agree given we need to work on use cases and requirements first
… in 8 weeks or so, we'll start new work anyway
Ege: should not work on new items then?
Koster: we could work on new items, but should clarify the use cases and requirements rather than jumping into the conclusion directly
… we could prioritize the proposed features based on the use cases too
Kaz: my own preference and suggestion is strictly concentrating on the basic planning and refactoring for upcoming 6 weeks
… then start discussion on technical details in collaboration with the Use Cases TF after that
… anyway, we're out of time today
… so let's continue the discussion next week
[adjourned]