Meeting minutes
Logistics
Ege: wondering if this slot on Thursday is OK for people
<kaz> (some discussion about people's availability)
Ege: Will send an email to ask other people's availability as well
TD
Initial Connection Restructuring
<kaz> TD PR 2090 - Initial Connection Restructuring
Ege: Simple PR, although the diff is quite big
… just turned the bullet list into a table
… will show you what it looks like
… (shows the rendered Markdown document)
… we now have a similar table structure as it is present in the TD spec
… then we have what each container contains, the rest I didn't change
… didn't want to make a big PR
… also wanted to ask whether we want to move the state machines and the requirements somewhere else
… currently it is a bit difficult to read
… the requirements can be visible in the diagrams
Kaz: As an initial starting point, we can make this description a separate group note and the think about how to restructure later
Ege: Why a group note?
Kaz: If we are unsure how to integrate the content into the main TD spec, we could have a separate document
Ege: The main blocker is the toolchain
… could have it as a separate document, but I am open to opinions
Kaz: Waiting for the toolchain is also fine
… just started to wonder about the possibility of a group note
… would make it possible to also get comments from the public
Ege: A readme is not enough?
Kaz: Might be even better to have it as a group note for that purpose for better visibility, but we can also wait
Ege: Then maybe as a question to the group: Do you prefer a classic group note or is markdown okay for you?
<cris> +1 ok for markdown (sorry I lost most of the discussion )
Ege: Maybe just from my side: As soon as we put things into a group note, people think it is a standard
… so I would prefer to make it obvious that it is not a standard
Kaz: The process document is clear about that, but people do not understand that, that is your point, right?
Ege: Yeah, similar applies to CG notes
Daniel: Agree, it is also less overhead
… the only issue with Markdown I see is that linking is not working as well
… but other than that Markdown is fine
Ege: Okay, if there are no other opinions then I would keep it in Markdown format
… any opinions about moving the diagrams within the document?
… there were also some comments by Luca
… (adds a comment to the PR summarizing that the reordering is fine for the group as well as sticking to the Markdown format for now)
… will apply remaining changes and merge asynchronously
Container Parsing
<kaz> TD Issue 2093 - Initial Connection Container Parsing
Ege: The next step would be to do the container algorithm
… which could be based on the merge-patch algorithm or the JSON-LD algorithms
… as the only spec with algorithms is the Scripting API at the moment, I wanted to ask how we want to proceed here, should we use WebIDL?
Cristiano: In the Scripting API task force, we are usually starting with an issue, then write up the algorithm as text
… could start with a PR
… however, the Scripting API algorithms are usually relatively simple, this might be more complex, so maybe we could try to split up the problem into smaller chunks
… also need to think about data types
Ege: There is already a PR
… (shows a rendered Markdown table)
… this is what you mean?
Cristiano: Yeah, we are going to stick to Markdown, right?
… looks good already, we can then start working on the other aspects
Daniel: An example for what we do is the JSON-LD expansion, which looks very complex, we usually stop earlier and do not go as deep with the nesting
Ege: (gives an example for an algorithm)
<kaz> initial-connection/README.md
<kaz> Specifically, the TD Examples from the README.md
Ege: difficult to explain, but I think you got it
Cristiano: I think we might be able to build upon already existing assign algorithms
… if we look carefully enough, I hope there should already be pre-existing one
Daniel: We should also try to get implementation experience
Ege: Good point, already tried starting a simple script
… maybe we can leave the implementation to the invidual people, like Eclipse Thingweb, as versioning might be an issue here
… also annoying to deal with the software distribution aspects
Cristiano: Only exception in that regard are the TypeScript definitions by the Scripting API
Ege: Could be an issue if the spec gets published but the software lives on independently and gets updated
Ege: Will do some cleanup of the document and then next week we can have a first look at the algorithm
… will have a call on next Thursday
Reconsider "id" being optional
Kaz: I've just remembered that we got a response from the Privacy Group regarding the ID issue, so maybe you could mention that briefly
<kaz> i|I just|subtopic: Reconsider "id" being optional
Ege: (shows the response from the Privacy Group)
<kaz> i|shows|TD Issue 2054 - Reconsider id being optional|
Ege: by the way, kaz, is there a way to link to this?
Kaz: You can at least forward it to member-wot-wg@w3.org mailinglist
… (summarizes the response and his own latest message)
… there are some questions on the generation and the format of the ID
… so if it is going to be a MAC address, then the generation will be well-defined
… there needs to be a definition of a "session", that is whether it is going to be connected to multiple networks or not
… also need assertive language, as there is no compliance check of implementations
… need general guidelines and avoid "engraved" identifiers
… that was the discussion we had this week, only wrote back on Tuesday
… also wrote her that she is invited to join one of our calls
Cristiano: I think you covered most of our questions, and you are right that there are still a number of moving parts, in order to make sure that we do not create security or privacy loopholes
Kaz: Just wanted to repeat that we need to start with a high-level discussion with them again
… for example, just using id for identifying a specific session and ask for advice
… currently, we do not have any particular algorithm etc., so let's just start with a chat with them
Ege: Any other comments?
Jan: Looks promising, thank you for pushing this forward
Next Work Item Proposals
Ege: Initial connection seems to make a lot of progress, should now discuss which topic is going to be the next one we want to focus on
… we had this document with a lot of topics we want to focus on
… I wanted to propose the data mapping topic
<kaz> Data mapping
Ege: the other alternative would be focussing on use cases submitted by parties such as Use Case TF, TD TF or liaisons
… could also be from other sources
… in the end, we need to people who want to work on a particular topic
… if there is no one to work on something, it is not going to happen
… want to get input from as many people as possible
Cristiano: The first thing that comes to my mind is of course the whole discussion regarding manageable actions
… seems to me even more important than Data Mapping
… everything is connected, though, also relevant to pagination in the case of TDDs, but also action calls that run asynchronously etc.
Kaz: I think both of these aspects can be handled as part of the use case discussion
… so maybe we can perform a prioritization based on that
… Michael McCool was also thinking about a process of use case description generation
Ege: There is always going to be a use case/user story description, in order not to pull something out of thin air
… at the moment, enough people have already articulated the need
… so we just need to formulate the descriptions based on these considerations
Kaz: Maybe we can generate a lightweight description from some of the work items which we've been working on for a while
Ege: The others: What do you see as important aspects we should work on?
Koster: I basically agree, these are the most important ones, as they also point to pretty large gaps at the moment
Daniel: I think most of us agree that these are the most important topics to work one
Mizushima: Also agree
<cris> +1 for getting input
Ege: There has been previous work when it comes to managable affordances in the web agents group, so from there we can also get input
… also presentations that were held in the WoT context
… there have also be considerations to model managable actions via events
Ege: I am not sure whether we can work on both work items at the same time, so we might need to pick one or prioritize one over the other
… what do people think?
Cristiano: If you ask me, if we deal with managable actions we might deal with data mapping anyway
… so we might want to start with data mapping, but the dependency might be bidirectional
Ege: So maybe we want to work on both at the same time to a certain degree to find that out
Daniel: Ideally, we might want to have people work on both topics at the same time
… for that reason
Ege: Yeah, that would be the best case
Koster: We should do use case review on both, probably
Ege: Alright, then we should start working that next week
… and start separate markdown files like in the case with the initial connection
[adjourned]