rhiaroeprodrom: Best process is to have sarven and amy give us an update on status of the document so far and sounds like they want to move to FPWD, we discussed last week and decided to give people time to review
aaronpk... since the editor's draft, we've clarified a bunch of stuff and we think it's in a stable enough state and we have a more iplementations since last week
aaronpkeprodrom: I realized that LDN is more general than activitypub but there is a close relationship. has there been a discussion between amy and sarven and jessica and chris about the overlap?
aaronpkeprodrom: i think that we've had mixed theories about what FPWD means, whether it's putting something on rec track or just putting it out for discussion, i'm leaning towards the second
aaronpkcwebber2: i agree that there's a lot of similarities. amy and i have been talking, trying to figure out how to bridge things, because we'd like to make them as compatible as possible
aaronpk... the fundamental difference between the two is LDN is a lot more general, in that it doesn't assume as much about vocabulary used, which is nice in some ways
aaronpkrhiaro: things we can do if you're an LDN implementation and you want to support activitypub, then you have to serve your JSON as compacted JSON-LD so any consumer can read it as plain JSON
aaronpk... which might happen anyway. so things like that we can align on i think we can work things out so that LDN can serve stuff that plain activitypub implementations can handle and vice versa
aaronpk... one of the things this group has tried to do is that there's a lot of existing work, running code, how can we find common specs between those
aaronpk... it's great that amy has done some implementations of LDN already. where i start to get concerned is when we talk about how we could converge specs that isn't based on implementation experience. where we start having specs make compromises that break existing impls, but don't have any actual value
aaronpk... i want to call that out as a concern. while i agree that the general trend towards convergence is good, but premature convergence where people in a room agree on spec-first convergence that isn't followed up with implementation
aaronpk... if we are proceeding with the assumption that these are rec track, then we'll be implementation testing them. if we want to relax that assumption then we should do so explicitly and up front
rhiaro... One is waiting for the original poster to give comment, I believe they were going to bring it up at i18n telecon last Thursday so looking for some feedback on that
rhiaro... For activitystreams historically that title or displayName or name has not had markup in so that you can show it directly without having to worry about markup
rhiaro... but as a courtesy last week because jasnell was on vacation we decided not to resolve it without him. He's back but still on vacation and hasn't commented yet
rhiaro... At this point I'm getting concerned about where we are with the CR process. I would like to get some guidence from the group about what we do next
rhiarotantek: The challenge here with getting to CR is that we're supposed to take things to CR when we don't know any outstanding substantitive issues, that would alter implementations
rhiaro... Going to acknowedlge that there may be other ones filed that would cause the spec to change, which may mean there's a new CR, but tha'ts okay
rhiaro... Obviously yes if you're using the document for a reference that needs to be accurate, but in terms of normative stuff they're almost entirely editorial
rhiaro... The way that we solve the multiple list of properties problem is typically by making one normative and the others non-normative and point back to where they are normatively defined
rhiaro... The other option is that if we honestly believe these are not going to affect implementatiosn we have to make a very strong case to the director to say we have these outstanding issues but we still think the document should go to CR and here is our case. Hard but not impossible
rhiaroeprodrom: I think that my main concern is that we went through a process that we resolved all the issues and decided to go to CR and did the transiton request and that from start to finish took about 4-6 weeks
rhiaro... I'm wondering if we would be restarting the clock ont hat or if we can just say we resolve these issues then go to CR without th emeeting again?
rhiaroeprodrom: great. That's good news. I'm going to let james know that we are waiting on publication for him and then also double check with Richard that we've satisfied him on 338
rhiaro... Once you've got the draft edited to resolve the issue Richard needs to take another look to check those sections align with his understanding
rhiaro... So if you do want to keep participating in this particular issue you can comment directly there. We're not taking it back to a resolution vote in the group
ZakimAs of this point the attendees have been rhiaro, annbass, eprodrom, dmitriz, aaronpk, sandro, csarven, ben_thatmustbeme, cwebber, tsyesika, tantek
eprodrom trackbot, start meeting
RRSAgent logging to http://www.w3.org/2016/07/19-social-irc
ben_thatmustbeme present+
aaronpk ... it's great that amy has done some implementations of LDN already. where i start to get concerned is when we talk about how we could converge specs that isn't based on implementation experience. where we start having specs make compromises that break existing impls, but don't have any actual value