Social Web Working Group Teleconference

12 Jul 2016

Attendees

Present: sandro, aaronpk, rhiaro, akuckartz, cwebber, csarven, wilkie, eprodrom, annbass, ben_thatmustbeme, KevinMarks, tantek
Regrets Chair: SV_MEETING_CHAIR
Scribe: cwebber2, rhiaro

aaronpk: here's the latest micropub draft, I've added in a link to the test suite describing what the test suite will do, I've added conformance and exit criteria listing all features you'd expect, basically spec infrastructure we did with webmention
... that's all in place now
... this should be ready to publish as CR, but since there were other issues addressed as well, I'd like to publish as a Working Draft

<sandro> +1 publish as WD

<eprodrom> cwebber2 yes

<aaronpk> changes described here http://micropub.net/draft/#changes-from-21-june-2016-wd-to-this-version

<sandro> (while waiting for CR)

<aaronpk> https://github.com/w3c/Micropub/issues/34

aaronpk: so the accessibility group looked over all 5 specs, only had comments about micropub, they said they'd like examples of posts including accessibility info, such as alt-text on an image
... I've opened this as an issue on micropub
... main issue is there isn't a syntax to provide alt-text of an image, because microformats doesn't either, and it's based on it
... so I've opened an issue on microformats to track that as well... so that's blocked until we can solve from MicroFormats side

tantek: from SocialWG perspective of studying proprietary APIs, have you done any background research as how twitter, instagram, etc have provided alt-text of an image, or if they do at all? if they don't that's also useful info

aaronpk: I will do research on other apis

tantek: ok

eprodrom: so I wonder if the alt text is really distinct from title or comment on the image, and if those are supported?

aaronpk: I believe from the accessibility point of view, alt text is different from title or description
... from what I've seen of people who actually consume alt-text of images, it's a description of the image, rather than what someone says about the post

tantek: that's my understanding as well, and twitter allows you to enter alt-text as a separate field in the ui
... so from a ux perspective, certainly a deistinction

aaronpk: the best path forward is to do some research on APIs and document that
... and continue discussion on the github thread

tantek: would you still like to publish a WD?

aaronpk: yes with everything as of today

<wilkie> alt-text is objective and a title is subjective. yeah, twitter is a good example of allowing one person to provide both types of description.

tantek: it may be good to discuss inline that there's an outstanding issue and summarize and link to it so that anyone else reviewing the draft can go "oh yeah someone took a look at this"

aaronpk: can do

<aaronpk> http://micropub.net/draft/

tantek: is there an ED the group can look at?

aaronpk: yes online here --^

<tantek> http://micropub.net/draft/#changes-from-21-june-2016-wd-to-this-version

tantek: looks like these changes are pretty minor, is there anything you'd like to call out?

aaronpk: most of the text is the same, the differences from webmention specifically is summarizing other parts of the spec

<tantek> http://micropub.net/draft/#candidate-recommendation-exit-criteria

aaronpk: eg the features, I created that from reading the whole spec and trying to describe a feature
... everything else I think matches webmention pretty closely

tantek: let's put a proposal down then for the request that aaron made to publish a new WD

PROPOSED new draft of micropub at http://micropub.net/draft/ with addition of image upload alt-text feedback

<annbass> +1

<akuckartz> +1

<aaronpk> +1

+1

<ben_thatmustbeme> +1

<rhiaro> +1

<eprodrom> +1

<wilkie> +1

<KevinMarks> +1

<sandro> +1

RESOLVED new draft of micropub at http://micropub.net/draft/ with addition of image upload alt-text feedback

tantek: that leads us to AS2 updates, assuming there are no other issues from micropub

aaronpk: correct

tantek: so AS2 I assume is eprodrom

AS2 update

eprodrom: sure, so we had CR transition meeting which went well
... we had one major element from meeting, which was at-risk features
... we could have as exit criteria which was that any features not implemented in at least 2 implementations need to be marked for removal
... making it possible to have a bit more of a process in removing elements
... we got pushback on this for probably some pretty valid reasons
... first of all, we didn't actually use the term "at risk" which is the proper term for w3c
... so we were putting every feature "at risk" but not flagging(?) them "at risk"
... the second is the question of whether it makes sense that everything at risk, with the reductio ad absurdum (?) that nothing is implemented, or we have a small set of features and types that don't really hang together or have relationship together
... so Ralph Swick(as acting Director for the CR telcon) has suggested that we identify a small number of classes which will definitely be in a future version, where we wouldn't be able to go forward without those types and properties

<eprodrom> http://w3c.github.io/activitystreams/core/#atrisk

eprodrom: so what I did for this version is there's a new editor's version you can see here, which includes the term at risk
... almost everything at risk, which gives 4 core types (object, link, activity, ??, question)
... and three types that almost would be impossible to get around using
... and those are not at risk, and I framed it as the negative, that everything is at risk except these things
... this could meet requirement of meeting without leaving a smudge on the table
... gives our implementers to give an opportunity to say "these are the types I can count on being there"

<eprodrom> http://w3c.github.io/activitystreams/vocabulary/#atrisk

eprodrom: and we have a similar section in vocabulary, however it just links to the core version
... so it's more of a "there are things at risk here", you can check which ones are in the core version
... so that's the first item
... the other item this week that was important was we got a good list of issues from the i18n working group

<sandro> https://github.com/w3c/activitystreams/issues?q=label%3Ai18n+is%3Aclosed

<sandro> https://github.com/w3c/activitystreams/issues?utf8=%E2%9C%93&q=label%3Ai18n%20

eprodrom: most of these were addressed by James, who did an omnibus pull request over the weekend, he can't be with us this time around, but what we have is a number of items about i18n in activitystreams

<eprodrom> https://github.com/w3c/activitystreams/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3Ai18n%20

eprodrom: thanks a lot to rhiaro for fagging the i18n ones

er

scribe: thanks a lot to rhiaro for flagging the i18n ones

<rhiaro> I didn't label them, I guess Richard did

scribe: second was using particular normative references
... we switched rfc??? to ????
... and RFC<etc> to <etc>
... there was a second class about how to do things like identifying direction and language of a document

<ben_thatmustbeme> can review all those at https://github.com/w3c/activitystreams/commits/master

scribe: so I think none of these will be controvercial

<eprodrom> https://github.com/w3c/activitystreams/issues/341

scribe: the one normative recommendation was that if there was not a way to identify the default language for a document that we recommend that implementers use the named map / content map / ** map properties rather than their default version

<eprodrom> {"name": "Evan Prodromou"}

<eprodrom> {"nameMap": {"en": "Evan Prodromou"}}

scribe: so instead of having {"name": "Evan Prodromou"} we'd have {"nameMap": {"en": "Evan Prodromou"}}
... we had originally typed out nameMap / summaryMap / etc to have multiple translations for a property
... it was recommended that if we could not show the translations? for a document, we should use these by default

<eprodrom> {"@context": {"@language": "en"}}

scribe: it is possible to set the default language for a json-ld document
... so you specify the language in the context

<eprodrom> {"nameMap": {"en": "Evan Prodromou"}}

scribe: james noted that there are some implmeentations that will not be using the json-ld structure, and so he recommended that we use the longer mechanisms
... he actually had text that said which we should use the map version
... my feeling is that these map versions... that was a normative change, deprecated properties replaced them with these map ones
... I think that instead we should suggest we should use the default language mechanism
... so I removed that normative change and I'd like to get some guidance
... so we have a case where the editors are not in agreement

<rhiaro> scribenick: rhiaro

cwebber2: A question for Evan - are you suggesting we use the json-ld style of content mapping?

eprodrom: for default language?
... That is the way you set the dfeault language for AS2 documents, we already do
... Thee question is should we make it a SHOULD to use the nameMap, contentMap, summaryMap, descriptionMap
... The reason we would do that is for implementation that refuses to look in that context for the default language

cwebber2: I don't have a strong opinion. I think that it's not a bad thing or very hard even if you're not using a json-ld processor to look in that context
... Assuming that you're not using.... I don't have a strong opinion

<cwebber2> scribenick: cwebber2

sandro: as clarification eprodrom, you say we already have the language thing, but that's a recent patch, right?

eprodrom: well it's inherit in json-ld

sandro: but it's never mentioned for activitystreams
... so I agree with the essence of your proposal, I think suggesting everyone look at the map versions of properties is too painful
... but I wonder if we can't do the @context language without the json-ld caveat
... and suggest that everyone SHOULD provide a @context language, and every reader MUST check the @context language

eprodrom: so we recommend that people use the @(context: )language?

sandro: yes

eprodrom: I thiiink that that makes sense, but some examples will need to change

sandro: yeah, in the real world that may be a change, but

eprodrom: that could be a search and replace I think, it's just a question of do we want to have happen

<eprodrom> "unk"

eprodrom: another possibility is that if we use a language tag which means unknown, that could be somethign we use here to specify that if there is not a language tag, assume it's UND (undetermined)

sandro: then we wouldn't need to change the examples

eprodrom: we should probably change the examples anyway

sandro: yeah

<rhiaro> Do we also need to alias @language to language to match everything else too?

eprodrom: it's nice to have it slim, but now we're making it a bit more complicated
... and I think that's okay

<eprodrom> "language"

eprodrom: the other option is to include a first class property

<rhiaro> scribenick: rhiaro

cwebber2: I think I'm all for the suggestion that we make it a SHOULD when you know the language and we also say the implementations must look at @context to look for it. It's not too tough to look there even if you're not using json-ld
... But I'm not sure that we should change every example in the activitystreams doc to include an @context with the language property, the reason being that there's a classic problem where people start wanting to provide a language with content they don't know, and suddenly you have a bunch of content in another language tagged as English because the programmer was lazy
... I think it's okay ot have some examples int here that might reflect that user submitted content is probably unknown in most cases

<sandro> +1 cwebber2 important to avoid giving @language when system doesn't know it!

eprodrom: Interesting point

<tantek> I agree with cwebber2 about not forcing a default language for exactly that point

<cwebber2> I have to reboot

<cwebber2> my phone

<tantek> hold on

<eprodrom> If you are typing, please mute!

<tantek> scribenick: rhiaro

rhiaro: I was thinking we can just alias @language to language and put the language tag on objects

sandro: The @language doesn't go on objects it goes in the context so that doesn't work

eprodrom: I'm not sure how that would work

sandro: It looks like in json-ld it can go in the ocntent if you're using the expanded form, but since you're using the compacted form there's no place for the language to go so it has to go in the context

tantek: sounds like there's more non-trivial discussion, so we can move on to other points. Do we have a github issue for this?

<eprodrom> https://github.com/w3c/activitystreams/issues/341

eprodrom: yes
... There is the question, I'm not exactly sure what happens next, but I think we push back publication. When do we make our decisions here and then go forward? Or do we fix after we publish?

tantek: the first part is there is non-trivial discusison, we're not going to get an answer on this telecon. We allow people to continue iterating on that issue, specifically cwebber2, rhiaro and sandro to chip in more
... Second is about publishing. Either we decide to publish with this issue outstanding in which case we may want to call it out explicitly in the draft
... Alternatively, up to you evan, is to wait to publish to resolve this issue first, then incorporate

eprodrom: At this point we can publish a working draft that *evan is cutting out*
... James needs to be here?

<tantek> something about not wanting to override James

<tantek> without James in the room

<eprodrom> I'd like to publish a WD and then look at CR next week

sandro: I think I heard Evan say he wasn't comfortable overriding one of James's decisions without James, so sounds like we need to wait until next week until James is back online and we can get his attention
... Sounds like wer'e close to a consensus

tantek: sounds like you had a similar approach, just figuring out syntax

sandro: No question what the syntax is. I don't believe there's a design decision

eprodrom: We've got two feet on the ground and it's which we want to lean on. I'd like to publish what we have as an ED as a WD, and that will make it easier for review
... With James's changes and the new at risk language
... Just won't have the normative change to recommend using the map properties

tantek: Can we call that out as an issue inline

eprodrom: Yep

<tantek> PROPOSED: publish AS2 documents as WDs with calling out issue https://github.com/w3c/activitystreams/issues/341 inline in the appropriate place in the document(s)

eprodrom: Perfect

<eprodrom> +1

<annbass> +1

<ben_thatmustbeme> +1

<wilkie> +1

+1

<KevinMarks> +1

<akuckartz> +1

<sandro> +1

<aaronpk> +1

<cwebber2> +1

RESOLUTION: publish AS2 documents as WDs with calling out issue https://github.com/w3c/activitystreams/issues/341 inline in the appropriate place in the document(s)

tantek: is that the end of the AS2 update?

tracking document status

<tantek> https://www.w3.org/wiki/Socialwg/DocumentStatus

UNKNOWN_SPEAKER: Any editors like to provide updated status?

ben_thatmustbeme: I was wondering .??. jf2 are we changing publish dates again?
... sandro could I have an update of what are we publishing and when?

sandro: So we could try to go ahead with jf2 by itself. I had been waiting for other things, but as you've heard the other things have been snagged on other issues
... I guess we might as well go ahead and do jf2 by itself
... Not sure of the status with post type discovery

tantek: I've had trouble with pubrules checks so I have a draft but it's not passing pubrules, so that has additional work
... I don't know if I can get those resolved in the next hour, but I don't want it to hold anything up
... But if there's a desire to cluster publishing.. sandro?

sandro: I think clustering is nice but not particularly important

tantek: we're waiting on AS2 and micropub for WD, not going to CR today, need to address the comments for the things that came up during review
... We don't have a new estimated date of CR for those, right?

sandro: assuming james and i18n hopefully we'll do AS2 next week, but I don't know how confident to be of that
... I think we will

tantek: similarly the accessibility issue with micropub if we get that resolved we could do next week for that too?

sandro: is the micropub issue blocking CR?

tantek: aaron?
... If it's a normative change that blocks CR

aaronpk: the accessibility issue asks for examples
... So I belive that doesn't intend to block CR

tantek: to be fair if their request is for examples of something the spec doesn't support, and the spec requires a change, that's a CR blocker
... We know of an outstanding normative change
... Can you provide an example without altering the featureset of micropub?

aaronpk: I guess technically no because it relies on microformats specifying how to do that

KevinMarks: there is a way to ?? content and that will just ???? markup
... The issue is do we need to define a more detailed set of properties for photo posts

aaronpk: I do think it needs to be handled explicitly
... alttext shouldn't be mixed with the content of a post

KevinMarks: The content is HTML

<KevinMarks> let me type that

tantek: if the editor thinks this should be handled normatively that means it's a normative change
... That's potentially possible for next week. aaron do you think you can do the resolution of this and any dependant issues by next week?

<KevinMarks> micropub parsing via microfomats can bring in the source html of posts via e-content

aaronpk: I think so, as long as we can make quick progress on the microformats side

tantek: Sounds like we may be abel to push everything forward a week
... Okay by me for PTD
... Ben is that okay for you for jf2?

ben_thatmustbeme: Fine waiting a week

<KevinMarks> that will preserve alt, figure, longdesc, aria any accessible html markup

tantek: new goal is to get everything in place for next week
... Please resolve any normative issues in github ahead of time
... That leaves SWP and AP

<rhiaro> No change on SWP

cwebber2: I've been pushing pretty hard on getting an implementation out there and am pretty close to giving a usable draft

<KevinMarks> the specfic issue will be for parsing photo explicitly, and if we need to define a new object for those to hold richer metadata in parsed form

<ben_thatmustbeme> sandro, i'm assuming you want me to rewrite those staged version with the new date (7/19)

tantek: by next week?

<cwebber2> tantek, sure

<cwebber2> tantek, I hope so :)

tantek: We resolved last week to accept LDN as ED

<tantek> https://www.w3.org/wiki/Socialwg/DocumentStatus

<rhiaro> We've got issues we're working through, and would like to go to FPWD soon, next week

tantek: Any more urgent issue?

<annbass> excellent job(s) everyone -- kudos!

tantek: Lots of work for everyone to do for next week
... If you're interested in changes happening, please review the changes as they're happening
... Talk next week

<akuckartz> thanks and bye!

<wilkie> thanks all!

<annbass> thanks tantek, cwebber2 and rhiaro

<wilkie> rhiaro++

<Loqi> rhiaro has 211 karma

<wilkie> cwebber2++

<tantek> rhiaro++

<Loqi> cwebber2 has 64 karma

<Loqi> rhiaro has 212 karma

<tantek> cwebber2++

<Loqi> cwebber2 has 65 karma

<cwebber2> :)

<tantek> oops

<tantek> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

publish AS2 documents as WDs with calling out issue https://github.com/w3c/activitystreams/issues/341 inline in the appropriate place in the document(s)

[End of minutes]

Socialwg/2016-07-12-minutes