Meeting minutes
<agenda bashing with minor updates>
TD Optional Content Type
TD PR 2081 - Make contentType optional in ExpectedResponse and AdditionalExpectedResponse classes
Jan: Added additional example about empty response
… I went through the assertions as well
… tried to align them
… no need to make contentType optional on all levels
… anyhow, change fixes original issue
Ege: I will look at it again
… to make sure assertions are fine
Ege: one aspect is about default value
… no requirement that response must contain contentType
… it would be good to show in example that there is an input
… in Example 37
Jan: A second example could also be provided
… would cover scenario we had in discovery spec
… about no body/contentType
Ege: Is there any other diff in the spec
Jan: Yes, in the assertions
<kaz> diff - 5.3.4.2.2 Response-related Terms Usage
Ege: I see. would be easier to check the Preview HTML than the diff.
<kaz> preview - 5.3.4.2.2 Response-related Terms Usage
Ege: looks good
Jan: I noticed that the same applies to additionalExpectedResponse
… turn it into formal assertion
Ege: I don't think it is needed, later sentence covers it
Jan: Mhhh, maybe this assertion needs to change then
Kaz: If there are 2 sentences/assertions, we should clearly separate them
Ege: As a list? Yes...
Kaz: Correct, we should think about a better style as well
Ege: Seems to be a ReSpec issue with not showing space between the 2 assertions
Jan: I wanted to suggest the same
… I can take a look
Ege: Great, gets close being mergable
Moving Arch Spec's Normative text
<EgeKorkan> TD Issue 2120 - Moving normative text from Architecture Specification about the TD features
Ege: Toumura-san started the work
Toumura: Created script to take over assertions
Toumura: Some assertions contradict
… for example number 15
… about "Form contexts and submission"
… we need to analyze assertions step-by-step
Ege: We need to look at conflicts
… those assertions are dangerous
… Toumura how do you want to move forward?
Toumura: We can use issue to comment on each assertion
… if we reach consensus then we can move on
Ege: Maybe we can edit issue instead of creating dedicated issue
… for more complex ones we can turn them into a dedicated issue
… the assertions already in TD we can remove/mark as such
Kaz: Thank you Toumura
… given that there are 54 assertions
… we might consider using separate MD file
… to check difference and/or matching
… creating 54 issues is not the right approach
Ege: Makes sense!
… I think we should create a new MD file
<EgeKorkan> https://
<EgeKorkan> https://
Toumura: will copy content over
Registry
How to deal with the registry entries before the Registry is finalized
<kaz> Registry Issue 22 - Registry Entries before the Registry is finalized
Ege: we discussed yesterday
… talked to Nigel from BBC, the TTWG Chair, about their Registry
… moreover, I read about class 4 changes
… I am a bit confused ... but it is possible in process document
Kaz: we can ask PLH for advice based on our draft at some point :)
Reformat Document
<EgeKorkan> Registry PR 17 - refactor: reformat document Section 6
Ege: It is a big PR
… at the same time no real normative changes
<EK shows preview>
… Mostly about section 6
… concrete content/text is the same
… assertions have been added in ReSpec style
… the diff shows lots of changes like changes in section and html
Ege: Is there any meaning change?
Daniel: No, not really
… it is mostly styling and HTML changes
Ege: Preview diff shows that very nicely
… any objections to merge?
… none -> merging
Ege: Some iterative work needed to move on
Registry Table
Ege: Adds table where binding lives
… I put a single placeholder entry
… table is too big
Daniel: I think I would live with auto-size
Jan: I would agree with Daniel
… can consider splitting information in 2 tables
… evaluate whether information can be grouped
Ege: Okay, I will remove the 190% from the PR
… splitting the content in table is difficult
… but we could move some things in summary document
… for example supported TD version .. or link
Kaz: related to procedure definition
… we need to clarify procedure as well, e.g., email discussion to be included into the HTML table or GitHub Issue template to be converted to the HTML table
Ege: Correct
… not critical for the first version
… we have an issue tracking the template
… fine by merging PR 21?
… no concerns -> merging
Ege: Remaining issue is about issue template
… w3c/
Daniel: Issue that terms defined are not used in document
Ege: Correct, we should fix that before publication
Daniel: Will have a look
Binding
PR 434
<EgeKorkan> Binding PR 434 - Retiring the main document
Ege: About retiring document
… document looks very simple
… abstract and SOTD which points to new location
… we should look at abstract ... which speaks about "retired document"
Ege: should speak about "latest" document before retirement
Kaz: Publish this document?
Ege: Yes
Kaz: I agree
<EgeKorkan> w3c/
Ege: Created addition to schedule
Kaz: It might be clearer to use the term "DISCONTINUED". I can talk with PLH about that.
Ege: Okay, let's wait for PLH's feedback about the terms.
PR 432
<EgeKorkan> Binding PR 432 - Adapting to Registry and Binding Word Usage
Ege: We looked at it last week
… Koster gaive feedback
Koster: I think document is fine now
Ege: No more objections -> merging
<kaz> [adjourned]