Socialwg/2016-07-26-minutes

From W3C Wiki

Social Web Working Group Teleconference

26 Jul 2016

See also: IRC log

Attendees

Present
sandro, ben_thatmustbeme, aaronpk, tantek, eprodrom, cwebber, rhiaro, csarven, annbass, dmitriz, KevinMarks
Regrets
Chair
eprodrom
Scribe
Ben Roberts

Contents





<tantek> heads-up: Evan is supposed to chair today per our regular schedule from the home page

<tantek> unless Arnaud is able to swap back for him since Evan chaired for Arnaud last week

<Loqi> ben_thatmustbeme: tantek left you a message on 2015-03-09 at 11:41pm UTC: yes thank you for the reminder re: chairing tomorrow. updated: https://www.w3.org/wiki/Socialwg/2015-03-10

wat?

<aaronpk> oh man haha

<aaronpk> i fixed the !tells

<Loqi> awesome

<eprodrom> About to join

<eprodrom> Arnaud: are you in?

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

<eprodrom> scribenick: ben_thatmustbeme

<scribe> scribe: Ben Roberts

yep

approval of last weeks meetings

Minutes for last week

<eprodrom> PROPOSED: accept https://www.w3.org/wiki/Socialwg/2016-07-19-minutes as minutes for meeting of 2016-07-19

if youl have a moment please review the minutes

eprodrom: i think there was an action to clear out the AS2 issues, but i'm not sure it got formalized in any way

<eprodrom> +1

<rhiaro> +1

eprodrom: I think the minutes are pretty good though

<cwebber2> +1

<ben_thatmustbeme> +1

<annbass> +1

eprodrom: if you have a opinion on the minutes please chime in

<csarven> +1

<tantek> +1 looks good

RESOLUTION: accept https://www.w3.org/wiki/Socialwg/2016-07-19-minutes as minutes for meeting of 2016-07-19

eprodrom: lets mark that as resolved and move on
... i have one admin item i'd like to move up here

reducing meeting frequency during August

eprodrom: we have done this during vacation periods before. During late july, early aug, people tend to be on vacation on lot
... so this is a good argument for reducing meetings, but we are on a limited schedule

<KevinMarks> present

rhiaro: If we move to bi-weekly formal meetings, i would suggest having informal Social Web Protocols meeting

<cwebber2> I'm for that if others are interested

rhiaro: just to make sure things keep moving until september as we have a lot of work to do

eprodrom: that sounds like a great way to lessen our load while still moving forward

<Zakim> tantek, you wanted to just note he'll be out Aug 9 and 16

tantek: i think thats probably a good suggestion. i have a few dates that i'll be away (listed in IRC)
... we have 5 telcons scheduled in august now.

eprodrom: how about we do the 2nd and the 23rd and have a two week gap

<eprodrom> PROPOSED: only hold formal WG telecons on Aug 2 and Aug 23 2016

sandro: so cancelling 9th, 16th, and 30th

<sandro> +1 works for me

<tantek> +1

<eprodrom> +1

eprodrom: and those would be good times for informal meetings

<aaronpk> +1

<cwebber2> +1 assuming we do the informal meetings

<ben_thatmustbeme> +1

<rhiaro> +1 assuming we can have inbetweeny meetings for spec editors

<KevinMarks> +1

<sandro> (not sure I can make the 23rd)

eprodrom: looks like sandro and tantek may be out for the 23rd. i think it would be bad to have 4 weeks off

<annbass_> +1

tantek: if i'm not chairing, i can at least listen in

RESOLUTION: only hold formal WG telecons on Aug 2 and Aug 23 2016

tantek: does that put Arnaud to chairing the 23rd?

eprodrom: yes, and i'm his backup
... great, lets move on to our actual work for this week

<eprodrom> julien?

welcoming Julien

<rhiaro> He said in email he'd be here

eprodrom: if not, the topic may not be worthwhile, he said he would be here, but he may have had trouble getting on to IRC
... if anyone wants to try on that email thread to contact him, maybe he will come in later

AS2 status

<tantek> chair: tantek

eprodrom: that is going to be me mostly just talking. tantek could you chair this segment

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

eprodrom: when we talked last week, we had a number of outstanding issues around internationalization that were in various states
... most of them have been resolved, the ones that have not been resolved are because there is some disagreement

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

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

eprodrom: one thats awaiting approval but i think was resolved. 337 was resolved to commenter's specifications. one of them is one that james objected to (344) so we are waiting for commenter. thats an editorial issue of where we include certain properties

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

eprodrom: there was one important normative one that we resolved through consensus (341) we did get feedback from jsnell and he was in agreement with the last proposal so there were no more objections to it

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

eprodrom: we had one non-editorial, normative change that is still outstanding. I would like some guidance from the group on it (338)
... the issue is around the name property
... everything in AS2 has a name, it was originally title, then display-name, then we resolved it to name. the previous versions of this property have not allowed HTML in the property.
... this would be for things like name of a video, title of a photo, etc. etc. etc. This likely comes from ATOM, which discouraged putting markup in the title property
... there is the stylistic of being similar to html, not having markup in the page title. The nice thing is for out-of-band display of an object
... so you could just use name and know that you do not have markup

<KevinMarks> atom title can have markup, fwiw

eprodrom: there would be some advantage for internationalization
... yes KevinMarks, you can, but you have to add some extra tags
... but the default is not to do it
... i think its also possible to do it with HTML, but it gets badly rendered

<eprodrom> name: "My recipe for gazpacho"

<KevinMarks> tantek used to confuse Reader by putting xhtml in his atom:title

<tantek> what KevinMarks means is that I would demonstrated bugs in Reader :P

<eprodrom> "My recipe for <span lang="en">gazpacho</span>"

eprodrom: the use came that came up was something like, "if you have a name like "my name is gazpacho'" its doesn't show that gazpacho is another language

you could do some extra markup for switching languages within a name

scribe: that is the motivation for adding markup to the name property

<bes_thatmustbeme> ... there is also the question of doing directionality

scribe: there is also a way to do this in UTF8
... its possible to do directionality without markup, its not possible to do language without markup

tantek: let me stop you for a second there for evan

aaronpk: i wanted to mention i had a siimilar issue against micropub, and i think the example you gave is not the core issue, its mostly about the directionality of text
... the problem comes up where you have both directions , left to right and right to left within the same string

<aaronpk> http://w3c.github.io/i18n-drafts/articles/inline-bidi-markup/uba-basics.en

<KevinMarks> "I pronounce <span lang="vi">Phở tái </span> like French for armchair, <span lang="fr">fauteil</span> "

aaronpk: heres a link to a draft that has been written up on this. the better issue on this is punctuation when it switches direction like a quote in text, and the punctuation in it needs extra data

<sandro> screen readers care about the language, I believe.....

aaronpk: the solution in micropub was you define a base directionality and there isn't much use to doing it on the word, but there is actual reasoning to directionality on punctuation. hopefully that gives some background to it as its pretty unfamilliar to many of us

annbass: has it been solved elsewhere?

aaronpk: only in HTML as you can specify directionality of any block

tantek: thats a problem in every json format then really

aaronpk: its a string encoding issue

<sandro> Example from that document, live: http://w3c.github.io/i18n-drafts/articles/inline-bidi-markup/uba-basics-data/isolation

<annbass> Richard Ishida = r12a

aaronpk: there is one question i'm asking him about, there is a unicode character for right-to-left-mark, and i'm asking to see if thats sufficient for it

<eprodrom> 'It will force people to convert to or use control characters for inline bidirectional controls, and will prevent inline annotation for language change.'

<annbass> W3C Team leader for Internationalization (i18n) ... world expert on i18n in web technologies

aaronpk: this was all on the micropub issue. i would suggest reading the intro that was written there
... i would suspect he's not really asking for markup in the name, but asking for directionality to be solved

eprodrom: i think he is actually asking for it, its in the title of the issue...

aaronpk: i think he's asking "why its not there" not actually "asking for it" which is very different

annbass: have you talked to him?

aaronpk: i didn't realize this was an issue on as2 as well

<csarven> W3C Web Annotation WG uses `oa:textDirection` with values like oa:ltr or oa:rtl. That however is for the subject.

tantek: whats odd about this is that this is an issue on any string encoding

<csarven> .. that is not for a particular property

<csarven> https://www.w3.org/TR/annotation-vocab/#textdirection

tantek: so i'm a little frustrated by it being brought up like its asking us to solve the problem for everyone else

<Loqi> [Robert Sanderson] Web Annotation Vocabulary

sandro: well there is a solution, use html

<annbass> that's my point, Tantek .. if this is a problem that needs a global solution, maybe a small team could work on ... including others from i18n and whatever other groups

eprodrom: we do use html in other properties, its just we don't allow it in this case
... from my POV the burden is put on implementers to have to sanitize it though
... its non-trivial vs a stirng that you can just HTML escape and just show on a webpage
... it would be putting a lot of AS2 consumers, for what seems to be only two use-cases

aaronpk: to be clear, i am in favor of not having HTML, but its an issue that would be possible to solve later

<cwebber2> relevant comic https://xkcd.com/1137/

(back and forth about what the commentor actually wanted, including quoting the issue)

<sandro> :-) :-) cwebber2

cwebber2++

<Loqi> cwebber2 has 67 karma

<tantek> cwebber2++ wow

<Loqi> cwebber2 has 68 karma

<annbass> hehe

<eprodrom> "It will force people to convert to or use control characters for inline bidirectional controls, and will prevent inline annotation for language change."

eprodrom: he seems to think thats sub-optimal but could work. but would not work for language change
... i'm not sure about this. it sounds like what you are saying we should do.... (incomplete thoughts)

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

<Loqi> [James M Snell] Activity Streams 2.0

tantek: cwebber has been on the queue

cwebber2: i agree with evan that it does raise the level of work for implementors
... i've certainly seen plenty of implementers just use the title and assume no html
... i also wonder, is the Unicode RTL method composable in HTML and whether or not that would make any impact

<Zakim> tantek, you wanted to note that we tried this for Atom with entry title with markup, and implementations failed to get interop.

<cwebber2> that's a good point

tantek: this whole, embedding markup in names thing actually made it in to the atom spec, i don't know why, but it did. so i tried putting that in my website just to test it across everything. the end result was that there was almost no readers that supported

<KevinMarks> or they did support it and it blew up their layout - when you put an <h2> in it

<sandro> +1 try giving that answer, maybe in spec

tantek: it led to bad interop on that property. so i would say to push-back strongly saying that it leads to bad interop
... i notice that a bunch of these are novel things, that is to say, its not really a criticism of this spec, no spec really supports that
... if you look at any existing APIs in the social space, and i'll bet you will find none who support this

<eprodrom> +1

<cwebber2> yeah +1 as well

tantek: so you could push back saying that if its such a strong use-case, why has no company had to deal with this before?

sandro: i think thats a reasonable response, but it might be worth noting in the spec why thats not supported

eprodrom: i'd be happy to maybe add this in our description of the name property, give a quick gloss on why it does not support HTML markup. for historical reasons, implementator experience, etc

<KevinMarks> mf2 can do this, but it isn't common http://www.unmung.com/?html=%3Cdiv+class%3D%22h-entry%22%3E%3Cp+class%3D%22e-name%22%3E%22I+pronounce+%3Cspan+lang%3D%22vi%22%3EPh%E1%BB%9F+t%C3%A1i%3C%2Fspan%3E+like+French+for+armchair%2C+%3Cspan+lang%3D%22fr%22%3Efauteil%3C%2Fspan%3E%3C%2Fp%3E%3C%2Fdiv%3E+&pretty=on

sandro: and a work-around of saying you can always put that markup down in some body-ish

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

<Loqi> [James M Snell] Activity Streams 2.0

<annbass> I think it is important to acknowledge the issue, but with explanations such as being discussed to say why we didn't solve it

eprodrom: i'd be happy to do that. is it possible for us to do this.... the suggestion that aaron made, i think james has already addressed in 4.7.1.1

<eprodrom> "Because the name (and corresponding `nameMap`) property does not permit HTML markup, the Unicode Bidirectional Control characters [ BIDI] may be used to identify text direction:"

eprodrom: I think that should probably be sufficient

<annbass> if we spoke Arabic or Hebrew, we'd probably be more sensitive to the issue

<tantek> annbass that sounds hypothetical

<eprodrom> "Explain why there's no markup in 'name' in the vocabulary document"

<Zakim> tantek, you wanted to note that not even HTML <title> allows nested markup :P

tantek: i wanted to bring up one more thing. the HTML <title> tag itself does not allow markup

<KevinMarks> because title is not in body.

<annbass> (I was just expressing my thoughts; not proposing text for summary)

tantek: i would suggest we could go further and say MUST NOT add markup to the title
... json-apis don't do it, html doesn't do it. etc

<eprodrom> +1 to tantek's point

tantek: and bounce it back to i18n, to say thay have a lot more work if they are just going to try to push this in to random specs

<cwebber2> well

<cwebber2> it's probably a very hard problem

annbass: my concern is that its a catch-22, if you say 'others don't do it, so we won't'

<cwebber2> so I'm not sure that it's the fault of other groups

<cwebber2> I agree to annbass' wording

tantek: its not a catch-22, its their job to define how to do it

<Loqi> Tantekelik made 2 edits to Socialwg/2016-07-19 https://www.w3.org/wiki/index.php?diff=99034&oldid=99010

<Loqi> Tantekelik made 1 edit to Socialwg/2016-07-26 https://www.w3.org/wiki/index.php?diff=99033&oldid=0

<Loqi> Tantekelik made 2 edits to Socialwg https://www.w3.org/wiki/index.php?diff=99041&oldid=98988

<Loqi> Rhiaro made 1 edit to Socialwg/2016-07-26 https://www.w3.org/wiki/index.php?diff=99035&oldid=99033

<Loqi> Eprodrom made 3 edits to Socialwg/2016-07-26 https://www.w3.org/wiki/index.php?diff=99040&oldid=99035

<Loqi> Aaronpk made 1 edit to Socialwg/2016-07-26 https://www.w3.org/wiki/index.php?diff=99038&oldid=99036

annbass: I think its better to at least accept that its an issue, but its not something we are going to solve in this group

tantek: i'm saying that if it was a problem, then it is a global problem, but given that every implementation for social space have not hit this issue, then i would qustion that the problem exists

<aaronpk> https://blog.twitter.com/2012/right-to-left-languages-on-twitter

<annbass> +1 on Sandro's point

sandro: can i suggest that we step back from this issue, and its not something we want to deal with in this group and just say that there is some historical reasons for not doing it right now, we are not going to push that ball uphill

tantek: sandro would you like to propose a resolution so we can push this through

<sandro> PROPOSED: We reply to r12a about as#338 and micropub #37 saying that we don't do HTML in these fields because implementation experience as with atom has shown it's too hard to implement / doesn't get implemented, and we think it's more important to have consistency

aaronpk: i'm only going to point out that in micropub #37 that he never asks for html in the property
... i did find the unicode control characters for this so i responded with that but have not heard back yet

<KevinMarks> fwiw, feedparser has test cases for atom with html titles in all 3 modes

aaronpk: my suggestion is to note that HTML is not the solution for that, in case that comes up

<aaronpk> this is a great post describing how twitter solved it https://blog.twitter.com/2012/right-to-left-support-for-twitter-mobile in short, they detect the number of RTL vs LTR chars and set the base text direction accordingly.

<sandro> PROPOSED: We reply to r12a about as#338 (and as far as it applies to micropub #37) saying that we don't do HTML in these fields because implementation experience as with atom has shown it's too hard to implement / doesn't get implemented, and we think it's more important to have consistent interop

<aaronpk> +1

<tantek> +1

<sandro> +1

<eprodrom> +1

<ben_thatmustbeme> +1

<annbass> but it doesn't get at Aaron's point that r12a didn't ask for HTML

tantek: any objections to that?

<KevinMarks> +0

<rhiaro> 0

<annbass> I'm fine with making a statement .. just needs to be accurate re: what Richard asked

<annbass> 0

<aaronpk> annbass, it's fine, we're not proposing closing the micropub issue with this

<annbass> ok

<annbass> could we work with Richard to find accurate language?

<cwebber2> oh

<cwebber2> +1

<eprodrom> annbass: yes we can

<cwebber2> with annbass wording though

tantek: given that we have given it a few minutes, and we have several +1s, lets declare this resolved to give a good consensus

RESOLUTION: We reply to r12a about as#338 (and as far as it applies to micropub #37) saying that we don't do HTML in these fields because implementation experience as with atom has shown it's too hard to implement / doesn't get implemented, and we think it's more important to have consistent interop

<tantek> chair: eprodrom

eprodrom: i'll do the response to richard and other additions
... we only have 2 miniutes left, i see 2 options, we defer micropug #36 to next week or we extend the meeting a little

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

aaronpk: i'd like to get the group to look at this its, short

eprodrom: lets extend a little

micropub issue 36

aaronpk: this is likely something that applies to other APIs, etc. it is basically about the error messages not containing anything for directionality, etc
... my proposal is that this is out of the oauth 2.0 spec that says these are specifically for developers and not user-facing

<tantek> sounds like a reasonable proposal

so i would specifically like to add that wording and that we specifically don't have a method for localizing those

<annbass> +1

<tantek> sounds like we could use a PROPOSED for that?

<eprodrom> PROPOSED: Adopt OAuth 2.0 language for error message purpose and defer any localization of error messages

<eprodrom> PROPOSED: Adopt OAuth 2.0 language for error message purpose and defer any localization of error messages in API result

<eprodrom> ROPOSED: Adopt OAuth 2.0 language for error message purpose and defer any localization of error messages in API results

<aaronpk> +1

<tantek> +1

<ben_thatmustbeme> +1

<eprodrom> +1

<cwebber2> +0

<KevinMarks> +1

<sandro> +1

eprodrom: if we could get some votes on that

<Loqi> nice

<rhiaro> +0

eprodrom: I don't see any -1s so i'm going to mark this as resolved

<eprodrom> PROPOSED: Adopt OAuth 2.0 language for error message purpose and defer any localization of error messages in API results

<rhiaro> +0 because I don't know enough, not unenthusiastic.. deferring to editor :)

<tantek> +1

RESOLUTION: Adopt OAuth 2.0 language for error message purpose and defer any localization of error messages in API results

what date are we publishing PTD, JF2, etc?

<annbass> thanks a lot Evan and Ben!

<annbass> and Tantek too

<eprodrom> trackbot, end meeting

<tantek> ben_thatmustbeme: today if we can

Summary of Action Items

Summary of Resolutions

  1. accept https://www.w3.org/wiki/Socialwg/2016-07-19-minutes as minutes for meeting of 2016-07-19
  2. only hold formal WG telecons on Aug 2 and Aug 23 2016
  3. We reply to r12a about as#338 (and as far as it applies to micropub #37) saying that we don't do HTML in these fields because implementation experience as with atom has shown it's too hard to implement / doesn't get implemented, and we think it's more important to have consistent interop
  4. Adopt OAuth 2.0 language for error message purpose and defer any localization of error messages in API results

[End of minutes]