#social 2016-07-26
2016-07-26 UTC
ben_thatmust, jasnell, tantek and eprodrom joined the channel
RRSAgent joined the channel
# RRSAgent logging to http://www.w3.org/2016/07/26-social-irc
Zakim joined the channel
# ben_thatmustbeme present+
# 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
# ben_thatmustbeme wat?
# ben_thatmustbeme kicks loqi
# eprodrom About to join
# eprodrom present+
# eprodrom Arnaud: are you in?
annbass joined the channel
# ben_thatmustbeme offers to scribe
# eprodrom scribenick: ben_thatmustbeme
# ben_thatmustbeme scribe: Ben Roberts
# ben_thatmustbeme yep
# eprodrom chair: eprodrom
dmitriz joined the channel
# ben_thatmustbeme Topic: approval of last weeks meetings
# dmitriz present+
# eprodrom TOPIC: 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
# ben_thatmustbeme if youl have a moment please review the minutes
# ben_thatmustbeme 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
# ben_thatmustbeme ... I think hte minutes are pretty good though
# ben_thatmustbeme <ben_thatmustbeme> +1
# ben_thatmustbeme s/hte/the/
# ben_thatmustbeme eprodrom: if you have a opinion on the minutes please chime in
# eprodrom RESOLVED: accept https://www.w3.org/wiki/Socialwg/2016-07-19-minutes as minutes for meeting of 2016-07-19
# ben_thatmustbeme is tempted to put minutes in pig latin some week and see if how long before anyone notices
# ben_thatmustbeme eprodrom: lets mark that as resolved and move on
# ben_thatmustbeme ... i have one admin item i'd like to move up here
# eprodrom TOPIC: reducing meeting frequency during August
# ben_thatmustbeme eprodrom: we have done this during vacation periods before. During late july, early aug, people tend to be on vacation on lot
# eprodrom ack rhiaro
KevinMarks joined the channel
# ben_thatmustbeme ... so this is a good argument for reducing meetings, but we are on a limited schedule
# KevinMarks present
# ben_thatmustbeme rhiaro: If we move to bi-weekly formal meetings, i would suggest having informal Social Web Protocols meeting
# KevinMarks present+
# ben_thatmustbeme rhiaro: just to make sure things keep moving until september as we have a lot of work to do
# ben_thatmustbeme eprodrom: that sounds like a great way to lessen our load while still moving forward
# eprodrom ack tantek
# ben_thatmustbeme tantek: i think thats probably a good suggestion. i have a few dates that i'll be away (listed in IRC)
# ben_thatmustbeme ... we have 5 telcons scheduled in august now.
# ben_thatmustbeme 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
# ben_thatmustbeme sandro: so cancelling 9th, 16th, and 30th
# eprodrom +1
# ben_thatmustbeme eprodrom: and those would be good times for informal meetings
# ben_thatmustbeme <ben_thatmustbeme> +1
# KevinMarks +1
annbass_ joined the channel
# ben_thatmustbeme eprodrom: looks like sandro and tantek may be out for the 23rd. i think it would be bad to have 4 weeks off
# ben_thatmustbeme tantek: if i'm not chairing, i can at least listen in
# eprodrom RESOLVED: only hold formal WG telecons on Aug 2 and Aug 23 2016
# ben_thatmustbeme tantek: does that put Arnaud to chairing the 23rd?
# ben_thatmustbeme eprodrom: yes, and i'm his backup
# ben_thatmustbeme eprodrom: great, lets move on to our actual work for this week
# eprodrom julien?
# ben_thatmustbeme TOPIC: welcoming Julien
# ben_thatmustbeme 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
# ben_thatmustbeme ... if anyone wants to try on that email thread to contact him, maybe he will come in later
# ben_thatmustbeme TOPIC: AS2 status
# ben_thatmustbeme eprodrom: that is going to be me mostly just talking. tantek could you chair this segment
# tantek notes https://www.w3.org/wiki/Socialwg#Future_Meetings has been updated with previous telcon resolution
# ben_thatmustbeme ... when we talked last week, we had a number of outstanding issues around internationalization that were in various states
# ben_thatmustbeme ... most of them have been resolved, the ones that have not been resolved are because there is some disagreement
# ben_thatmustbeme ... 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
# ben_thatmustbeme ... 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
# ben_thatmustbeme ... we had one non-editorial, normative change that is still outstanding. I would like some guidance from the group on it (338)
# ben_thatmustbeme ... the issue is around the name property
# ben_thatmustbeme ... 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.
# ben_thatmustbeme ... 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
# ben_thatmustbeme ... 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
# ben_thatmustbeme ... so you could just use name and know that you do not have markup
# KevinMarks atom title can have markup, fwiw
# ben_thatmustbeme ... there would be some advantage for internationalization
# ben_thatmustbeme ... yes KevinMarks, you can, but you have to add some extra tags
# ben_thatmustbeme ... but the default is not to do it
# ben_thatmustbeme ... 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
# eprodrom "My recipe for <span lang="en">gazpacho</span>"
# ben_thatmustbeme ... 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
# ben_thatmustbeme you could do some extra markup for switching languages within a name
# ben_thatmustbeme ... that is the motivation for adding markup to the name property
# ben_thatmustbeme ... there is also the question of doing directionality
# KevinMarks s/en/es/
# ben_thatmustbeme ... there is also a way to do this in UTF8
# eprodrom q?
# ben_thatmustbeme ... its possible to do directionality without markup, its not possible to do language without markup
# ben_thatmustbeme tantek: let me stop you for a second there for aaron
# ben_thatmustbeme 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
# ben_thatmustbeme ... the problem comes up where you have both directions , left to right and right to left within the same string
# KevinMarks "I pronounce <span lang="vi">Phở tái </span> like French for armchair, <span lang="fr">fauteil</span> "
# ben_thatmustbeme ... 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
# ben_thatmustbeme ... 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
# ben_thatmustbeme annbass: has it been solved elsewhere?
# ben_thatmustbeme aaronpk: only in HTML as you can specify directionality of any block
# ben_thatmustbeme tantek: thats a problem in every json format then really
# ben_thatmustbeme 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
# ben_thatmustbeme ... 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.'
# ben_thatmustbeme ... this was all on the micropub issue. i would suggest reading the intro that was written there
# ben_thatmustbeme .... i would suspect he's not really asking for markup in the name, but asking for directionality to be solved
# ben_thatmustbeme eprodrom: i think he is actually asking for it, its in the title of the issue...
# ben_thatmustbeme aaronpk: i think he's asking "why its not there" not actually "asking for it" which is very different
# ben_thatmustbeme annbass: have you talked to him?
# ben_thatmustbeme aaronpk: i didn't realize this was an issue on as2 as well
# ben_thatmustbeme tantek: whats odd about this is that this is an issue on any string encoding
# ben_thatmustbeme ... so i'm a little frustrated by it being brought up like its asking us to solve the problem for everyone else
# ben_thatmustbeme sandro: well there is a solution, use html
# ben_thatmustbeme eprodrom: we do use html in other properties, its just we don't allow it in this case
# ben_thatmustbeme ... from my POV the burden is put on implementers to have to sanitize it though
# ben_thatmustbeme ... its non-trivial vs a stirng that you can just HTML escape and just show on a webpage
# ben_thatmustbeme ... it would be putting a lot of AS2 consumers, for what seems to be only two use-cases
# ben_thatmustbeme 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/
# ben_thatmustbeme (back and forth about what the commentor actually wanted, including quoting the issue)
# ben_thatmustbeme cwebber2++
# eprodrom "It will force people to convert to or use control characters for inline bidirectional controls, and will prevent inline annotation for language change."
# ben_thatmustbeme eprodrom: he seems to think thats sub-optimal but could work. but would not work for language change
# ben_thatmustbeme ... i'm not sure about this. it sounds like what you are saying we should do.... (incomplete thoughts)
# ben_thatmustbeme tantek: cwebber has been on the queue
# ben_thatmustbeme cwebber2: i agree with evan that it does raise the level of work for implementors
# ben_thatmustbeme ... i've certainly seen plenty of implementers just use the title and assume no html
# ben_thatmustbeme ... i also wonder, is the Unicode RTL method composable in HTML and whether or not that would make any impact
# ben_thatmustbeme 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
# ben_thatmustbeme ... it led to bad interop on that property. so i would say to push-back strongly saying that it leads to bad interop
# ben_thatmustbeme ... 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
# ben_thatmustbeme ... if you look at any existing APIs in the social space, and i'll bet you will find none who support this
# eprodrom +1
# ben_thatmustbeme ... so you could push back saying that if its such a strong use-case, why has no company had to deal with this before?
# ben_thatmustbeme sandro: i think thats a reasonable response, but it might be worth noting in the spec why thats not supported
# ben_thatmustbeme 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
# ben_thatmustbeme sandro: and a work-around of saying you can always put that markup down in some body-ish
# ben_thatmustbeme 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:"
# ben_thatmustbeme eprodrom: I think that should probably be sufficient
# eprodrom "Explain why there's no markup in 'name' in the vocabulary document"
# ben_thatmustbeme regrets volunteering to scribe
# ben_thatmustbeme 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.
# ben_thatmustbeme ... i would suggest we could go further and say MUST NOT add markup to the title
# ben_thatmustbeme ... json-apis don't do it, html doesn't do it. etc
# eprodrom +1 to tantek's point
# ben_thatmustbeme ... 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
# ben_thatmustbeme annbass: my concern is that its a catch-22, if you say 'others don't do it, so we won't'
# ben_thatmustbeme 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
# ben_thatmustbeme 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
# ben_thatmustbeme 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
# ben_thatmustbeme 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
# ben_thatmustbeme tantek: sandro would you like to propose a resolution so we can push this through
# ben_thatmustbeme wonders who is talking randomly
# ben_thatmustbeme i wasn't going to call out name :P
# ben_thatmustbeme names*
# ben_thatmustbeme rests his hands
# ben_thatmustbeme aaronpk: i'm only going to point out that in micropub #37 that he never asks for html in the property
# ben_thatmustbeme ... 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
# ben_thatmustbeme ... 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
# eprodrom +1
# ben_thatmustbeme <ben_thatmustbeme> +1
# ben_thatmustbeme tantek: any objections to that?
# KevinMarks +0
# eprodrom annbass: yes we can
# ben_thatmustbeme tantek: given that we have given it a few minutes, and we have several +1s, lets declare this resolved to give a good consensus
# sandro RESOLVED: 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
# ben_thatmustbeme eprodrom: i'll do the response to richard and other additions
# ben_thatmustbeme ... we only have 2 miniutes left, i see 2 options, we defer micropug #36 to next week or we extend the meeting a little
# ben_thatmustbeme aaronpk: i'd like to get the group to look at this its, short
# ben_thatmustbeme eprodrom: lets extend a little
# ben_thatmustbeme TOPIC: micropub issue 36
# ben_thatmustbeme aaronpk: this is likely something that applies to other APIs, etc. it is basically about the error messages not containing anything for directionality, etc
# ben_thatmustbeme ... my proposal is that this is out of the oauth 2.0 spec that says these are specifically for developers and not user-facing
# ben_thatmustbeme so i would specifically like to add that wording and that we specifically don't have a method for localizing those
# 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
# ben_thatmustbeme <ben_thatmustbeme> +1
# eprodrom +1
# KevinMarks +1
# ben_thatmustbeme eprodrom: if we could get some votes on that
# ben_thatmustbeme 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
# eprodrom RESOLVED: Adopt OAuth 2.0 language for error message purpose and defer any localization of error messages in API results
# ben_thatmustbeme what date are we publishing PTD, JF2, etc?
# eprodrom trackbot, end meeting
# RRSAgent I have made the request to generate http://www.w3.org/2016/07/26-social-minutes.html trackbot
# bigbluehat rhiaro: with great power...
# ben_thatmustbeme comes lots of people annoying you to use it for them
# tantek rhiaro: other than a few false-negatives from pubrules, https://tantek.github.io/post-type-discovery/index-wd.html looks good to go dated for 2016-07-28
# ben_thatmustbeme rhiaro: sorry, i got distracted, this has been ready for a while. just updated the dates in it http://dissolve.github.io/jf2/publish/
shepazu_ and tantek joined the channel
shepazu joined the channel
# tantek ALL: Draft agenda for next week's telcon is up: https://www.w3.org/wiki/Socialwg/2016-08-02
# tantek Please add any discussion items here: https://www.w3.org/wiki/Socialwg/2016-08-02#Discussion_Items
KevinMarks joined the channel