Meeting minutes
Agenda
Sebastian: plan today is to prep for next WD
… want to go over PRs and merge as much as possible
… and then would like to call for review based on the version today, so in two weeks we can make a resolution for the next WD on Dec 22 in the main call
… then look at the binding topics
minutes review
<kaz> Dec-1
Sebastian: publication plans, name spaces, PRs
… still some open PRs that were not merged, e.g. for OAuth
… also issues about IANA requirement
… removal of TD canonicalization
… note that version just before canonicalization was removed was branched
… then discussed various issues, e.g. TDs with no IP address
… P Blum came up with example that had a dynamic IP
McCool: I do have a question about how frequently you do this
… if there is a DHCP every few days then re-registering with the directory is not a big deal
McCool: single base is just a common-case optimization in my opinion btw
Lagally: I do have a question about what to do when there are multiple forms
Sebastian: different implementation strategies; node-wot uses the first entry that is supported
… daniel also discussed this in profiles
… other approaches might be to always use the first one
Lagally: why have multiple options then?
McCool: also a use case with different security schemes; maybe client wants to use oauth rather than passwords
Lagally: if use "first that works" then there needs to be a timeout, etc.
Sebastian: these are implementation details...
… can be decided on application side
McCool: propose that we discuss this in profiles, not here... TDs allow multiple forms
Ege: btw, if send request to one, and it does not reply, something wrong
McCool: is a counter-example to that (cloud/local), but we can talk about it elsewhere
Sebastian: issue about diagrams?
… propose we leave them be, to clean them up needs manual work, let's do that for CR only, not for WD
… much easier to update using automatic tools
McCool: question; if diagrams must be informative, is there any information in a diagram (for example, superclass relations) that are normative but not in the text somewhere?
… see conformance section...
… diagrams are informative, technically
Kaz: suggest we focus on reviewing the minutes for now
Sebastian: ok to publish minutes?
… no objections, will be published
TD publication plans
Sebastian: new WD for Dec
… some PRs today, merge
… resolution on Dec 22
McCool: wondering if we should suppress "editor's notes"
PR 1264
<kaz> PR 1264 - Fix 948 (add OAuth2 flow examples)
Sebastian: we have a security issue - add oauth cycle
McCool: one word was changed, unfortunately this changes the meaning
… the PR changes that one phrase
Sebastian: perhaps we fix it in the review phase
McCool: we could merge it and do a cleanup PR
Sebastian: you should decide, if it has security impact
McCool: go ahead and merge, we will discuss in security next week
Kaz: we should update the main Wiki and add "cancellations" for next week, if something is cancelled
McCool: we will have the security call next week
Sebastian: I will assign you Michael, probably Cristiano will take over
… we merged, thanks for your work
PR 1284
<kaz> PR 1283 - update webhooks example
Sebastian: #1283: did not have time to work on that
Lagally: we have multiple level of affordance
… need to provide metadata for actual events
… need some kind of additional metadata
… people tend to think about typical scenarios
… but we need to think about multiple levels
… related to the Profile discussion
Sebastian: (shows example 66)
Sebastian: note this is just an example
… to be honest I'm not very happy with this example
Ege: we could still work on webhook example
Lagally: yeah
… but could be still part of the example
… that's an important sentence
Ege: certain set of payload is used
… in some protocol, you can get property
… but may be not necessary
… don't think we really need to do this in a prescribe manner
Lagally: you don't know where it came from
Ege: once the event arrives, can be sorted out
Lagally: let's have discussion during the Profile call
(some more discussion)
Sebastian: webhooks/events is a well-known problem
… this is in an annex area currently
… if profiles have established an approach, we can add a link here
Lagally: need to leave soon, can we look at arch-related Pr
Kaz: one question; people are not satisfied with the webhooks PR?
Sebastian: it is a little improved; it's not wrong, but it's not straightforward and raises many questions
… but ml had some additional comments to further improve it
Kaz: strongly suggest we talk about several use cases, what clients, who sends what to whom
Sebastian: in general this needs to be deeply discussed
Kaz: point not only how, but what and why
Sebastian: TD wants to be generic, focusing on one approach disallows other approaches
… but a drawback is we don't have useful details
PR 1301
McCool: clear definition of protocols and usage to be indicated
… ideally by the TD spec itself
Sebastian: potentially by the Binding Templates doc
McCool: think we should use subprotocols here; specific ways and details for how to handle events
Sebastian: there is also a comment from ege
… the link refers to the entire protocol binding doc, not a particular section
McCool: or rather, to an entire section, not just the part about the URI scheme
… could add an id to the given paragraph, but frankly not that long, so
Sebastian: we could also add a new column in the table for the URI scheme
… in section 4.1
Ege: perhaps we should merge and create an issue to clean this up, and ask ml to comment
see issue #1301
Kaz: wondering about relationship between 8.3 and the binding templates doc
… similar to problem in arch document
Sebastian: I think 8.3.1 probably should be moved to binding documen
… it was there in TD1.0 because binding doc was not complete
… but now it is, so... we can move this out
Kaz: we need to re-think about current status being normative
McCool: one issue is the use of default values
Ege: to understand, idea was to move these examples to the HTTP protocol binding doc
Sebastian: kaz mentioned we should be careful to avoid redundancy
Ege: we talked two or three weeks about this
Sebastian: I think we proposed moving this section
… issue #1274
Ege: also, already in TD 1.0, so if we remove it does it cause a compatibilty problem
Kaz: as we have been discussing in arch, we should clarify what is in normative TD doc vs. informative protocol binding doc
Sebastian: so should we merge this?
Kaz: think we can merge it if would be helpful for structuring discussion
Sebastian: it does help with arch statement regarding URI schemes
… (comments added to issue #1274)
… need to double-check with ml
Kaz: We can merge this PR if Lagally is also OK. It seems to me Lagally is already starting the structural relationship discussion by his comments. So I thin we can merge this but should start the structural relationship right away.
Sebastian: ok, will merge
PR #1309
<kaz> PR 1309 - New sub-sections to improve reading in Section 6.3
Sebastian: just added another level of subsections to make things easier to navigate
… in examples
… that way people can jump directly to a section that addresses their interest
McCool: concur that this is good and needed
Sebastian: unfortunately looks like there were some conflicts
… (resolves)
… (merges)
PR #1315
Sebastian: from ege, additional urivariables example
… examples using query parameters, etc.
… so have both direct URL modification and another one for queries
Sebastian: looks like you forgot the render
… please run render quickly
PR #1320
McCool: only one ednote left, relates to tags for validation
… also, they are just commented out, we can revert them easily
PR #1317
<kaz> PR 1317 - Adding id to tables
Ege: not ready to merge yet
… added ids to tables, like examples, so can link to them
… but complicated since some tables are autogenerated
McCool: this is purely editorial, we can skip it for now
Sebastian: we could also use captions, put links there
Ege: ideally respec would do this for us
Kaz: if this capability should be in respec, you should specify behaviour and ask respec team
PR #1318
<kaz> Issue 1276 - New TD 1.1 namespace IRI
Sebastian: new namespaces for TD 1.1
… see also #1276
… we discussed various options, and had a consensus, and also got ok from PLH
… also discussed omitting the date, but this is not aligned with our 1.0 namespace
… and we should use the same pattern
… MAYBE for 2.0 we can go to a pattern without the year
… avoids having things look outdated
… be aware there is a distinction between context and ontology files
… change context namespace only, not ontology namespace
Ege: somewhere in the text we say the context should be such and such, as opposed to in a table
Sebastian: know what you mean, I think I covered that
Ege: some were informative, e.g. in examples
Sebastian: did update all the examples
… let me check the source code
Ege: actually, check index.html because might have come from an ontology file
… or look at the rendering
Sebastian: found a problem, in section 5.3.1
… after table, context url is mentioned explicitly, needs to be updated
… ok, now fixed
Kaz: ok with this PR, but we should clarify location of ontologies files, what redirections we have to set up, etc
PR #1319
<kaz> PR 1319 - Make forms inherited from a base form
Sebastian: brand new
Ege: about validation schema
Sebastian: so not ready to merge yet
PR #1315
<kaz> PR 1315 - add more urivariables examples
Ege: finished, pushing now
… adding more uriexamples, but now fixed
Sebastian: looks good, let's merge
… (merged)
other PRs
Sebastian: remaining PRs do not seem critical, WIP or do not affect spec directly (validation schemas, etc).
WD/Review Readiness
Sebastian: are we ready to start review?
McCool: can still do editorial changes in the next couple of weeks, but should avoid major changes
… also I think good to have a resolution
<sebastian> proposal: the group decided to strat the review process based on the latest editor draft that can be found here: https://
RESOLUTION: the group decided to start the internal review process based on the latest editor draft that can be found here: https://
Sebastian: please read the doc carefully
<kaz> [adjourned]