Social Web Working Group Teleconference

26 Jul 2016

Attendees

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

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 gazpacho"

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 Phở tái like French for armchair, fauteil "

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

accept https://www.w3.org/wiki/Socialwg/2016-07-19-minutes as minutes for meeting of 2016-07-19
only hold formal WG telecons on Aug 2 and Aug 23 2016
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
Adopt OAuth 2.0 language for error message purpose and defer any localization of error messages in API results

[End of minutes]

Socialwg/2016-07-26-minutes

Social Web Working Group Teleconference

26 Jul 2016

Attendees

Contents

approval of last weeks meetings

Minutes for last week

reducing meeting frequency during August

welcoming Julien

AS2 status

micropub issue 36

Summary of Action Items

Summary of Resolutions