Meeting minutes
Approval of minutes of last meeting
<antoine> https://
<Jakub> +1
<FranckC> +1
<Arofan> +1
<RiccardoAlbertoni> 0 ( i was not there)
<Dan> +1
<annette_g> we need a proposal
<annette_g> proposed: accept last week's minutes
<antoine> PROPOSED: approve minutes of last call https://
<nicholascar> +1
<annette_g> +1
<FranckC> +1
<RiccardoAlbertoni> 0
<Jakub> +1
<LarsG> +1
<YoucTagh> +1
<Dan> +1
Minutes of last call approved
<Stephen> +1
RESOLUTION: Minutes of last meeting approved
public-dxwg-comments mailing list
<antoine> https://
antoine: we inherited a public W3C comments mailing list - it is not often used. What should we do with it?
antoine: Comments now come in via GitHub, but the mailing list has not been deprecated. However, past versions of the specs refer to the mailing list.
nicholascar: We should remove all references to old mailing lists, and turn the mailing list off. There are too many, and they cause problems due to the number. They should be tidied up.
annette_g: Will people use GitHub to make general comments? It should be well advertised if we do that. It would be nice to keep the old mailing list available for past references. A replacement must be easy to find.
antoine: We have the possibility to archive it, which seems to be W3C policy. We can just send a last e-mail shifting people to GitHub, and then close it for new comments. We should discuss this with Pierre-Antoine.
antoine: We should find out if it is possible to have an automated response to people who mail the list after closure.
<RiccardoAlbertoni> Please consider that in the dcat rec we have explicit reference to the old dxwg git and the comment mailing list
<RiccardoAlbertoni> so we should investigate if we can change this in a published rec without to release a new version
ACTION: Talk to Pierre-Antoine if we can implement this (archive the old list and close it with a solution for notifying people who try to use it)
publication process and Echidna
antoine: W3C is rolling out Echidna for publication of specs. Every time a PR is merged with the main branch, a new working draft is created, however. This is not how the DXWG has operated in the past - working drafts have been published by agreement.
antoine: We can ask TFs to merge changes into side branches until general approval to publish a working draft, to avoid unwanted publication. People should be OK with this process...
<nicholascar> PR for an Echidna test for dx-prof: w3c/
<gb> PR 86 Trivial abstract tweak (by nicholascar) [editorial]
nicholascar: Has done a test (trivial change above) to determine the results of a pull request. Once approved, we will see what the effects are.
annette_g: The proposed process seems good. A separate release branch from the master would make reviewing the proposed releases easier.
antoine: Does the Editor's draft already serve the function Annette proposed? Could we use it for this?
annette_g: An Editor's draft would be a release to the release branch, correct?
nicholascar: The repository controls can handle this how we want.
<RiccardoAlbertoni> +1 to maintain the review grace period on the editorial draft and explicit group vote for publication; how to manage it in a compatible way with Echidna might need some experimentation, side ranch might be a solution,
ACTION: Wait for Nicholas' test, and then - if OK - we adopt the proposed process with accomodation for Annette's proposal (using Editors's Draft, etc.)
<annette_g> most people use "main" now to avoid the word "master".
Lars: Is there a W3C policy?
<annette_g> +1 to checking for existing policy
antoine: We can ask Pierre-Antoine about the way Echidna functions, and if there is a W3C standard policy about what constitutes the main branch.
Annette's comment regarding "main" and "master" noted.
handling dependency on vocabularies in limbo
antoine: How do we deal with vocabularies which are defunct, but on which we have dependencies? A formal policy is probably not required at this point, but we should discuss.
<RiccardoAlbertoni> https://
FranckC: The problem has been discussed in the DataCube TF, because it has a dependency on the SDMX Content-Oriented Guidelines. This is an external group in the UK which has not maintained it. Should we porte this into a W3C controlled namespace and update? What to do?
LarsG: The URN review group has been looking at SDMX URN resolution. Could we use this for linking instead? It would be more stable.
RiccardoAlbertoni: [technical issues for staying in the call]
antoine: We'll continue the discussion next time, also allowing Riccardo to talk about the DCAT case.
ACTION: Dead vocabularies will go to agenda for next meeting.
task force calls
<gb> Sorry, I don't know what repository to use.
antoine: Are there any issues with organizing TF calls?
annette_g: We need to have a bit more notice for meeting scheduling, given the time zone differences especially.
<Stephen> will task force meetings show up on https://
nicholascar: We can arrange meetings better in future.
YoucTagh: One idea is to have an agenda beforehand, and see what items people have, and make sure the meeting is at an acceptable time for the people with interest in those items.
YoucTagh: Profile TF meeting we discussed use cases, and how to organize the work around them (they have separate GitHub repos).
antoine: This topic pushed to the next call for discussion.
<annette_g> I spent a long time trying to find minutes for the prof task force this past week.
<antoine>Yousouf will post them.
<YoucTagh> should I post them on a new github repo (as we 2 for the profiles TF) or use one of them?
<antoine> anyone of them; it's probably better not to create a new one. Or send an email. We don't want to mandate one solution at this point, like using the W3C system that we use for general calls. It's up to the preference of each TF, for now, as long as agenda and minutes are shared somehow.