– DRAFT –
DXWG Plenary March 12, 2019
12 March 2019
you can remove me from regrets
I can scribe
<kcoyle> https://www.w3.org/2019/03/05-dxwg-minutes
section admin
<DaveBrowning> 0 (not present)
proposed: accept last week's minutes
<DaveBrowning> 0 (not present)
<kcoyle> +1
<alejandra> +1
<roba> +1
+1
<riccardoAlbertoni> 0 ( i was not there)
(I wasn't there, but I accept the minutes anyway)
<Makx> +1
Resolved: accept last week's minutes
kcoyle: first thing to look at is that we are getting to the end of our time (end of June).
we need to assess where we are, if we need an extension.
kcoyle: phillippe is here to answer our questions about that.
kcoyle: let's go through our deliverables list for plh's benefit.
plh: how far are we from CR for DCAT 1.1?
alejandra: last week we spent two hours discussing pending issues, determining relative importance. In addition to several editorial changes, some are quite significant, e.g., how properties are shown
<kcoyle> https://w3c.github.io/dxwg/dcat/
alejandra: each class describes the different properties, but if they are inherited we just list them as inherited. we want to improve the presentation of these.
alejandra: we knew last year that we needed to set a date, but we never had a clear final date. Now we have set mid-March, and we are there but not ready.
kcoyle: how much time do you think you need at this point?
alejandra: we haven't discussed that. It's difficult to say. There are some concrete proposals for things that seemed to have been solved before. We are definitely not ready.
kcoyle: do we have to have an actual date?
plh: if you want to have an extension
kcoyle: what do we need to be doing to have the CR? Is that a final doc?
plh: CR means it is pretty close to final, but you can still make changes. Big changes would be a setback.
So how long would it take to get the substantive issues close to resolved?
kcoyle: back in December, we asked the DCAT group to do a division between what has to be in and what could stay out.
alejandra: we had that discussion at the face to face. We have made progress with our sprints, but there are still some issues that some people want to get resolved
plh: could we push those issues to the next version?
plh: Once you have CR, you have to gather implementation experience. You have three steps, CR, proposal recommendation (at which point we ask members at large to review), and then recommendation.
We want to make sure we have recommendations maintained. The group could release 1.1 by June and keep working on 1.2. That's perfectly fine.
<alejandra> here is the spreadsheet of the analysis of issues that are done, those that are critical to include, those that won't fix, and those that still need revision: https://docs.google.com/spreadsheets/d/17Du2hZzIxejX7MT6MlmZOIdMKFonrLRUUAn1v5XJwt4/edit#gid=0
We are considering introducing a new process track, the evergreen track. I can provide pointers to discussion about that.
Makx: An opinion, I'm in favor of doing a time-based decision. What we have is what we have. We could go on forever, but we need to publish something. I think we should close the work and not admit new things.
kcoyle: that sounds good
plh: I think we are at that stage. We could produce 1.1 as feature complete.
alejandra: this is not what people have been discussing in the DCAT group. We have assigned people to the issues. There are still some people thought were important to include. If we do the evergreen track, could we continue working as a working group?
plh: whether it's an evergreen rec or a regular one, we want you guys to keep maintaining DCAT over the long term.
plh: are the issues raised against new features?
alejandra: some of them are
plh: I think those will need to be pushed to the next version of DCAT.
alejandra: the ones in the spreadsheet are not the only issues.
kcoyle: Is there something in the doc that is very obviously broken? That you feel you cannot go forward without addressing?
alejandra: we've been trying to respond to things people have raised, but there is not total agreement.
kcoyle: you could propose that we deal with those things in the next version.
<alejandra> the editorial issue I mentioned before is this one: https://github.com/w3c/dxwg/issues/766
plh: my take is like, you guys should move to a call to move to CR at the end of the month. What would we need to address between now and then.
kcoyle: Makx's proposal would work here, set a date and use that as a cutoff.
plh: it would help for people to know that there is a path to 1.2.
plh: some groups create a branch, some keep working in the same branch in github.
At some point, it becomes a burden if you have to deal with more than one branch, depending on new features and where people are working on them.
kcoyle: would that be a new working group, or a community group?
plh: we are interested in keeping the working group around.
plh: just for 1.1, but I don't see any reason we wouldn't keep it for 1.2
DaveBrowning: Is this a normal way of operating?
we are saying the next version will be around comparatively soon, right?
What I'm worrying about is if someone looks at the 1.1 spec and really doesn't like something, will 1.1 on its own be complete.
plh: 1.1 should be feature complete. Tickets need to be labeled as editorial or deferred to the next version.
DaveBrowning: so we need to focus on issues raised as defects rather than new features?
plh: right. Push new features aside for next version. In the next 2-3 weeks, we need to focus on fixing what is broken in 1.1.
kcoyle: Do we need anything right now from the folks working on DCAT?
plh: what is important now is getting DCAT 1.1 done. 6 months later, we could have 1.2 ready for review. Some groups only do it every 5 years, but others are on strict timelines because they have a hard time finding a cutoff. People may be bummed because their feature didn't get in, but at least we have a recommendation.
kcoyle: do DCAT folks understand what they need to do?
alejandra: I think the main issue is the services proposal. People who don't usually join the DCAT group should join tomorrow (like annette_g).
kcoyle: it's already integrated, right?
Only in the pull request, and it's a big one.
<kcoyle> https://lists.w3.org/Archives/Public/public-dxwg-wg/2019Mar/0287.html
kcoyle: I pulled together all the issues. Conneg seems to be in pretty good shape, but I don't think we have anyone on the call who can speak to that.
<kcoyle> https://w3c.github.io/dxwg/conneg-by-ap/
kcoyle: the spec still has quite a bit of "cruft" in it.
I'm not sure it's a good idea to send it out as a second draft in that condition.
Previously, we haven't published them in such rough condition.
roba: I would concur that there's a lot of stuff in there that should be cleaned up and closed before it goes out. Phillippe is right on the money with focus on feature completeness. I think the work done to process the substantive comments has left us with mostly editorial comments. I thin the spec if ready to go and just needs editorial polishing.
plh: my threshold for publishing is extremely low. If what you have is better than what you have in TR, then publish. It's a working draft.
<Zakim> alejandra, you wanted to ask about implementation evidence
plh: I'm all for publishing often rather than getting it perfect.
alejandra: I may be jumping back, but this may be useful for other groups. In our implementation report, we only need to show use of the new terms we've proposed?
plh: yes, that's perfectly fair to concentrate only on the new features.
roba: I have no objection to what's there going up as a second draft, and it's feature complete.
kcoyle: I asked Nick in email if the group could have a list of what has changed.
roba: do we vote to release it now?
kcoyle: after people have had a chance to review with that in mind.
roba: so we need a list of what has changed to the group.
kcoyle: two other deliverables we have are the profiles guidance doc and the profiles vocabulary.
The profiles vocabulary has quite a few issues.
We need to figure out what to do here. I don't think we can do both of these.
One is in the charter and the other is not.
What do we do about this one that we haven't worked on much?
plh: The priority is DCAT. After that, the other docs can move along on their own timeline.
kcoyle: that sounds good.
If folks want to work on the other doc, it gets done. If not, it doesn't get done.
roba: I agree there hasn't been a lot of work on the profiles guidance.
The profiles vocab is pretty feature complete, but most issues are about clarification. It's not intended to be a replacement of SHACL or SHEX. There's a question about how much we align it with DCAT. That just changes the choice of a predicate name.
I need to implement this in another standards organization. Most of the issues are about the feedback process. I'm not too worried about the profiles vocabulary. There's a lot of work in responding to issues and closing them, but no big risks to the nature of the beast. The profiles guidance doc is different. It's not clear what it will offer people in terms of value and where the work will be coming from.
kcoyle: The profiles vocabulayr got 35 comments, but none of them have been closed. I think some of them are pretty substantial. At least some number of them need to be addressed before the people who made them will be happy. We need to respond to them and see if they can be made happy with where things are going.
roba: I agree it's important to respond to those issues. They have been looked at by the people working on the vocabulary and considered in terms of what needs to change in the model. We've made one change to the model. It's being dealt with systematically. The editors are addressing those comments.
kcoyle: I would like to see them addressed. Let's have the people say whether they feel it's been addressed. We may need to triage. But that process has to happen. We can vote on some things, like with the roles.
<roba> the one vote necessary is re DCAT alignment
kcoyle: We need to make sure the group agrees on the roles. We need to do more work on the definitions. I sent a comment out last week.
roba: There is a link to a google doc where we have a list of definitions and collecting comments that people are welcome to add to.
<roba> https://w3c.github.io/dxwg/profilesont/#Class:ResourceRole
roba: The roles now are in the draft.
kcoyle: The group needs to discuss the roles.
roba: most of the comments are addressed by the improvements in definitions.
<roba> +1
kcoyle: I'm a bit wary about putting the doc out without addressing external comments.
roba: we can put it out there and say we made an attempt, and ask for more feedback.
<roba> added roles, removed base specification, improved definitions examples and diagrams
kcoyle: we should give the working group a short description of what's changed. People will need a chance to look at it as the whole group.
roba: there is a list in the chat.
kcoyle: putting it in the document would be handy.
plh: yes, that's useful.
<plh> https://www.w3.org/TR/css-values-3/#changes
Action: roba to add the list to the document, following the model used in the CSS working group.
<trackbot> Created ACTION-311 - Add the list to the document, following the model used in the css working group. [on Rob Atkinson - due 2019-03-19].
kcoyle: there's room for more explanation, which I think is helpful.
say we clarified this, etc.
plh: people can click on the issue for details.
kcoyle: one other thing, the question has come up as to whether we will meet face to face in Japan in mid-September.
plh: you'll be done by then, no?
kcoyle: yes, shouldn't we assume that?
plh: it's in Japan, so assuming people would be able to travel there, you should do a survey of group participants to see their interest level.
kcoyle: they wanted an answer by mid-April
plh: say you might want a room.
plh: plan for success
Succeeded: s/resolved?/resolved