Meeting minutes
Agenda
Sebastian: <agenda bashing>
<kaz> Agenda
Kaz: would like to discuss normative sections
… can we clarify normative sections by End of November?
Sebastian: Yes, should be possible
… will add backlog to agenda
Previous minutes
Sebastian: SK walks over minutes
… Ege reporting on binding topics
Daniel: see FIXME subtopic
… we might want to change that
Kaz: Fix it
Kaz: Issue or PR about validator / link checker?
… link checker should be applied to static html
Ege: seems to still report some issues with repsec docs
… for TD there is such an issue
<Ege> here is the issue on td: https://
Sebastian: any objections before merging?
… none -> minutes approved
TD roadmap
https://
Sebastian: agreed 12 months extensions
… however, we should stick to 6 months schedule
… w.r.t. TD I have a good feeling
… wonder whether we should release another working draft
… could use WD for wide-review
… any opinions?
Ege: +1
<cris> +1
<kaz> (Kaz is OK as long as our spec work makes steady progress based on the updated plan.)
Daniel: wonder about the reason. Increase visibility?
Ege: I think static version is good. Stays stable while review phase
Sebastian: Agree
Sebastian: Social media mentioning is also nicer
Kaz: It might make sense to define procedure
… static html for wide review. For example, the DID WG defines a snapshot version for wide reviews and put that some specific location.
Sebastian: McCool mentioned discovery plans to do the same
McCool: I will definitely would like to see a discovery update
Sebastian: No decision needed now. Just keep that in mind
PRs
OAUth
McCool: We should hold on this PR
… I do have pending comments
Cristiano: I am looking forward to the review
McCool: big OAuth2 write-up in security section.. need to be aligned
Cristiano: Issue#948 asked for explanation
McCool: a "client" example might be easier
… referring to security best practices document
Cristiano: Sounds good to me
Update TM and tm generation script
PR 1272 - Update TM and tm generation script
Cristiano: Fix for other PR .. missing TM schema
Sebastian: Looks good -> merging
fix titles and descriptions type problem + default value entries for security
PR 1275 - fix titles and descriptions type problem + default value entries for security in
Sebastian: We do have a bug in current editors draft
… w.r.t. MultiLanguage and security parts
… some more issues "with default" missing
… the PR fixes the issues
McCool: I guess it broke when the rendered script was updated
Sebastian: Took me a while to figure out the problem
Jan: Short question: Is there a risk that this might happen again for next version?
Sebastian: Added some notes in render script
… for 2.0 I think we might reconsider the render script process
… highly depends on SPARQL
… Victor is expert in
… maybe we need to find another solution
… for the moment it should do the job
Cristiano: Other downside is that render script depends on 2 libraries developed by Victor
… I agree, for the future, we might look for other solutions
Sebastian: Yes, let's talk about this once we work on 2.0
Cristiano: JSON format / template could be an idea
Sebastian: objections before merging?
… none -> merging
add additional sample terms in sample sections 7.1.1
PR 1277 - add additional sample terms in sample sections 7.1.1
Sebastian: it is about semantic annotations
… renamed example section
… includes schema.org
… new is software version (coming from schema.org)
… it is just about examples
Sebastian: comments?
Ege: Do we say that people can look into schema.org ?
… to make sure that they can find new terms on schema.org
Sebastian: Yes, we could point people to schema.org
Ege: Yes, we should avoid such issues coming up over and over again
… people asking for keyword that exists already
Sebastian: I got the idea
Jan: Like room information?
Ege: yes, but there are many such issues
… hence we should promote schema.org and others
Sebastian: there is a nice database
<sebastian> https://
Sebastian: btw, we might want to change "s" prefix to "schema"
… in the example
Kaz: In any case we should clarify our own documentation
<kaz> Data Catalog Vocabulary (DCAT) - Version 2
Kaz: the data catalog specification might be helpful
Kaz: no need for normative specification
… but best practices might be useful
… possibly for the next charter period
Sebastian: Agree
Jan: Not related to PR. Does it make sense to create FAQ?
… to avoid such questions in the future
Sebastian: General FAQ?
Jan: Dealing with different topics
… creation of new TDs
… just something to keep in mind
Sebastian: I like the idea but it is matter of work and who keeps it updated
Ege: We can also link the issues with "FAQ"
Sebastian: Labeling makes sense
… or discussion feature?
… could talk about the topic in marketing task-force
Ege: will do
Sebastian: objections to merge PR#1277?
… none -> merged
add security aspect in intro + small type fix
PR 1278 - add security aspect in intro + small type fix
Sebastian: security was missing in intro
… is now added -> 5 aspects
… fixed also another small bug
… it seems a commit is missing
… will have another look
print *all* code parts on print
PR 1279 - print *all* code parts on print
Sebastian: at the moment the spec document is not very good for paper print-out
… for tabs you miss the "other" content
… DP added CSS for @media print
Daniel: Note, PR still misses changes for index.template.
… tab header is show in the beginning... afterwards the content sections
Sebastian: I see, let's revisit it next week
<McCool> (sorry, I have to drop. I cross-referenced an issue in security-best-practices with TD PR1264 so we can follow up)
Add changelog
Sebastian: Ege lists changes
Ege: I went through spec document
… did not check the associated issue
Sebastian: Yes, we should try to find out the related issues to get a even better overview
Daniel: Do we want to add the issues?
Sebastian: Yes, but would suggest to merge the current state
Cristiano: Thing model had multiple issues
… How do we handle it?
Sebastian: Listing multiple issues? separated by comma?
Cristiano: OK
Jan: Question: Sample TD
… should every feature have a sample TD?
Sebastian: It is more about testing / PlugFest
… "Implementation" is also important since we need 2 of them
Ege: I think we can revisit it after testing is done
Kaz: I was wondering about purpose of this proposed section.
… changelog should simply list additional features
… if we want to mark which feature is implemented by what.. is more implementation report
Sebastian: I see the list as nice overview
… what is "new"
Sebastian: Agree, it is not high priority
… other metadata is nice to have
Jan: For future versions ... should every PR add such an entry
… would facilitate the work in the end
Sebastian: Ege re-used old document to track new stuff
… unfortunately this did not work out
… but I agree, automatic logging would be nice
Jan: Could use PR template to remind us
Ege: Yes, would really help
Sebastian: +1
… maybe using GH actions?
Ege: not sure if this is possible
… easy way is to ask people
Jan: Could be just be a check, like "feature" label
Ege: +1
… should start with template and then look at GH action
… I guess only Kaz can create such templates
Sebastian: Ege, can you make a proposal?
<kaz> TD Editor's Draft - D. Recent Specification Changes
Kaz: Not sure if this approach is so good
… we have been generating the changes list in the past
Ege: Who was doing it?
Kaz: Not sure if we need this automation
Sebastian: this was manually created
… auto-generation would be nice
… no high priority tough
… template helps already
Kaz: then everybody is required to create a small PR for each feature
Ege: I have some thoughts w.r.t. assertion tester
… this assertion tester (changes) might help also
… Ben F. was asking for new things
… the PR was to make clear for everybody to see the changes
Sebastian: the list is mainly about the features
… new features
Kaz: we should not create this list separated from changelog section in the spec
… information itself is ok
… we need to maintain this list
… maintenance should be done by assertion tester tool
Sebastian: Ege, do you think we can align it with assertion tester?
Ege: It is in our todo list
Kaz: will talk about the tool from McCool on Friday
Ege: Can also merge for now but mention it is not optimal
Kaz: If the feature list is complete... we can merge
… one more comment
… text about TD maintenance version is confusing, should use v 1.1
Ege: was there before, but we can change it
Kaz: identical information at 2 places is confusing. We should have a single place
… information should go into spec document
… hence we don't really need this MD file
Sebastian: Suggest to leave it as it is for now
… I see Kaz point about multiple places
… fear inconsistencies
update webhooks example
PR 1283 - update webhooks example
Sebastian: relates to issue https://
Sebastian: combination cancellation container and unsubscribe op is confusing
… PR creates 2 examples for webhooks
… once it uses cancellation
… the other time it uses uriVariables and unsubscribe resource is used
… Hence, I simply separated the examples
… I also gave short explanation
Ege: Still one issue
… uriVariables in the TD is not the right way
<Ege> https://
Ege: currently uriVariables describe query parameters
Sebastian: I do recall such a discussion in the past
… I think it should work as used in the example
Ege: IETF specification allows it... but I guess the TD is not clear
Sebastian: I see
… let's have another look and improve warning/references in the TD spec
<Ege> https://
Sebastian: Ege, can you have a look?
Ege: Yes
… I guess we need another example also in the TD
Sebastian: Thanks!
add a note about observe behavior
PR 1284 - add a note about observe behavior
Sebastian: coming from scripting
… I added a note
Daniel: Need to take a close look
Sebastian: Okay, let's postpone it to next week
Cristiano: Quick comment: makes sense
… just worried about recommendation
… no guarantee ... since someone can change the value between reading and observing
… will add a comment
Sebastian: I see
… "recommendation" is not like a MUST
Issues for v1.1
Sebastian: would like to point everyone to https://
Kaz: Should contact also PLH besides Ralph
<kaz> [adjourned]