Socialwg/2016-08-02-minutes
Social Web Working Group Teleconference
02 Aug 2016
See also: IRC log
Attendees
- Present
- akuckartz, rhiaro, cwebber, aaronpk, dmitriz, tsyesika, annbass, KevinMarks, r12a, eprodrom, julien, tantek, r12a, sandro, csarven
- Regrets
Chair - tantek
- Scribe
- rhiaro
Contents
<tantek> scribenick: rhiaro
<tantek> https://www.w3.org/wiki/Socialwg/2016-09-22#Registration
<Loqi> Social Web WG Face to Face Meeting in Lisbon (F2F7)
Next f2f at TPAC
tantek: please register, pay the fees, and add yourself to the wiki page
... The w3c has hotels with blocks of rooms, they're filling up very quickly, fairly close to the venue, so another reason to act quickly
... Register and book rooms today
... our f2f is 22/23 of Sept. You should also try to be there for the 21st
... which is the technical plenary day, where there are breakotu sessions and talks
... In past tpac sessions we've had one or more breakouts on social or decentralised web that bring in new participants
... Last year AnnB helped moderate a good session
... Please see if youc an sign up for Weds, Thurs and Fri of that week
<tantek> PROPOSED: approve last week's minutes https://www.w3.org/wiki/Socialwg/2016-07-26-minutes
Minutes from 2016-07-26
<annbass> +1
<aaronpk> +1
+1
<tsyesika> +1
<cwebber2> +1
<akuckartz> +0 (did not participate)
RESOLUTION: approve last week's minutes https://www.w3.org/wiki/Socialwg/2016-07-26-minutes
PuSH
UNKNOWN_SPEAKER: eprodrom?
<sandro> eprodrom...?
Micropub issues
<eprodrom> I'm here
<sandro> are you on the call eprodrom ??
<sandro> okay, hear you now!
eprodrom: I'm not sure ... we had Julien ... I'm not up on where we are with PuSH right now
tantek: We need to discuss next steps for PuSH, but we can postpone
eprodrom: is Julien on the call?
... Let's make sure he's on the next call
sandro: Last week he apologised for putting it in his calendar wrong, but said he'd be here this week
tantek: If Julien calls in we can get back to discussing about it
<aaronpk> https://github.com/w3c/Micropub/issues/34
aaronpk: We're blocked on 34, being able to specify alt text for creating images
... We've been iterating on the microformats side of it separately and now have a proposal for how that translates to micropub
... I don't think we need to vote on it or anything it's just.. I'm happy with this solution, everybody else feel free to chime in on that github thread
<aaronpk> https://github.com/w3c/Micropub/issues/37
aaronpk: And since we have r12a here we might be able to get some more context around some of the other issues pending on mp, in particular I'm interested in 37 and that issue is about specifying language or direction of name or other parameters
... Have some back and forth in that thread and waiting for a response
<annbass> r12a=Richard Ishida, lead of Internationalization (i18n) work at W3C
r12a: Can I talk about it in a few minutes, because we're going to be talking about the same thing for AS2?
aaronpk: That's fine if we can do them all in one go, not a problem. That's all I wanted to bring up about mp right now
tantek: Any other outstanding issues on mp?
aaronpk: There's a couple
tantek: substantive
aaronpk: there's one possible one about when the configuration is not implemented by an endpoint should there be a required response to indicate it's not implemented
... This was opened last night, so I think we can continue on github for a while longer
tantek: So other than 37 and last night's, they're all resolved?
... again
aaronpk: Either resolved or working on addressing editorially
tantek: sandro, what are the next steps for micropub? We've had the CR transition call and there wasn't an explict no and now we're not sure what to do next
sandro: You pinged Ralph yesterday tantek and he just replied about an hour ago
... the short answer is that 1 tiny edit to h-entry linking to the stability thing and then we can go ahead and publish, we don't need another meeting
... there may also be a thing about internationalisation. If we want to make changes to address i18n concerns, we need to make sure everyone is satisfied before going forward with those changes, but assuming the are we don't need another call
PuSH
tantek: Welcome Julien! Great to have you here
Julien: Hello!
<julien> hello!
<sandro> hi!
<julien> presence +
<tantek> present
julien: sorry it's been such a mess these past weeks, I'm dedicated to making it here in time in future
tantek: The topic is PubSubhubbub and we want to discuss the next steps in terms of bringing the spec to the WG and starting with an ED and hopefully going to a FPWD
sandro: There's some mechanical stuff in terms of... if I understand right you have ac urrent draft I saw a few months ago. We want to get it into a new repo under w3c on github and roughly the right format
... Last week I sent you an email to a pointer to one of the other specs
julien: That seems fine, I need to work the details out
sandro: Normally the process is the editor prepares the draft, the group reads over it, we raise issues on github, we talk about them if their non-trivial, and do an iteration cycle where every once in a while we publish a Working Draft to get commetns from outside the group
... We're in a hurry because it's late in the life of the WG, but that doesn't change the basic process
... a big question in my mind is how close the latest draft that you've worked on is to something that we think is ready to actually publish that people could use
... I'm not a great expert in this space, I haven' tused it, but I know when I read through the spec I thought there were some underspecified bits, and I understood some other people have, the indiewebcamp wiki has some parts that specify the underspecified parts to get ineroperability
julien: I need to look at the indiewebcamp requirements, I can defintiely look at this and try to merge the comments and fix whatever is missing
sandro: If I understand right, this is 0.4 and from 0.3 you took out a bunch of the xml stuff that many of us where happy to see go, but left a bit of a hole there
julien: I can see hwat you mean. The initial versions of PuSH were targed to rss and atom feeds
... The goal with 0.4 was to make it agnostic in terms of mime type so it can work with json or html or anything else
... What we lost in the transition is the fact that xml or rss has for example diffing mechanisms that are clearly defined
... That we dont' have for other types of resources like json
... So I guess these are the parts that might be underspecified. Is there something else?
sandro: That's what I was thinking of
julien: Unless there is a global diffing emchanism that I don't know about I'm not sure how.. we could always revert to a text-based diff, but for things like json there might be smarter ways to do it
sandro: I don't remember exactly, but if that's exactly what it is I think we could.. since the http patch verb came along theres' a notion of mime types for patch formats so we could sort of refer to that and say you can use whatever you want that has to be some specified patch format
... I don't remember if that's all that there is, but that might be one option
julien: In eed to look again, I understood patch format was char level diffing, but if we can map the behavoiur there that should work
<aaronpk> https://indieweb.org/how-to-push
aaronpk: Just dropping a link to the post referenced previous. I wrote this up when I implemented a PuSH Hub, as well as publishing to that hub, where the things I'm publishing are html pages with h-entry markup
... For that constraint, this is what i ended up doing
... The idea being that if anybody is publishing similar h-entrys on an html page, this is an interoperable way to do that
<KevinMarks> with feeds, you usually add to the top and remove from the bottom (wiht time order) so patch will not necessarily help
aaronpk: I totally understand that PuSH itself is agnostic to the content
... But what I've found useful in specs that are agnostic to content like that, having a recommendation for how to handle a partiuclar type of content is useful
... That way the implementation that do have that content type in common can interoperate
... So that's basically what this page is
... PuSH 0.4 for html with h-entry
... I could definitely see writing a similar tutorial for say using PuSH with AS2 JSON
... But the problem right now with the 0.4 spec two people publishing and consuming AS2 JSOn may end up doing it differently but still following the spec
... SO adding to the spec that you *have* to do it one way ensures they're interoperable
julien: makes sense
tantek: julien, what do you think of taking an action item to review the details aaronpk has written to see if they're compatible with what you've written in push 0.4 and hopefully something you'd consider adding. Not sure how many implementations there are, but that might be on way to help move the spec forward
julien: sure I can definitely do this. I'll ping aaron if i have comments or issues
tantek: awesome
... We should formally as a group have a proposal to add PuSH as an ED
sandro: we made an agreement to invite julien to join and do this, so Amy and I will go ahead and make the repo and set permission to write to it, and when he has something for us to review, we can look into linking to it and so forth
tantek: don't we have a separte step first where we accept that we're going to take on something as an ED?
sandro: We need the draft in hand to do that
tantek: Iw as going to propose that with current 0.4
<cwebber2> fitzpatrick right?
sandro: Are there people who have been associated with PuSH in the past (in particular bradfitz) and whether in the name of politeness we should double check whether they want to be involved
... Or if anyone is in active contact with him
julien: I can ping them both though I doubht either will have time or interest
sandro: I'd like them to feel invited
... We'd be more than happy to have them help
tantek: Makes a lot of sense. We'd appreciate that julien to give them anopportunity to participate. No obligation, just make it clear that we're open to their participation
... Mostly want to make sure they know that
... And that there are no objections
<KevinMarks> is Bret still maintaining the google hub?
sandro: and if you could cc the chairs or the WG to confirm to them that you're acting on our behalf in inviting them
julien: sure, I'll do this
<julien> KevinMarks: no I don't think so
tantek: Then we'll leave it to 3 weeks from now to do the next steps there. Don't let that stop you, once you have teh repo set up keep iterating on it, go ahead and review
... go back and forth on details with aaron. We'll bring it up again for discussion at our next telecon on 23rd
sandro: informal telecons the next 2 weeks
tantek: a request to keep the slot for editors who want to have editing discussions
<KevinMarks> we can maybe ask Brett who is, if we want it updated infuture
sandro: julien, if you make some progress and you want feedback from the group feel free to send email to the group
<tantek> ack KevinMarks, you wanted to say something about time ordered feeds
KevinMarks: We're not trying to do arbitrary diffing here. PuSH assumes that you're adding stuff to the top and take stuff off the bottom. It may be worth writing a little piece in it saying assume there's a list and you can assume new things have been added
... Implied in aaron's writeup, but we can extend to other formats. Worth making that model clear, not arbitrary diffs, but adding new things to a list of things
tantek: My assumption is that push is not just for new items that shwo up at the top, but for potentially updates to existing items and perhaps even deletions
julien: yes that is the case
... There's a mechanism called tombstones where people publish empty entries with a previous id to mean a deletion
... but to Kevin's point, I don't think anyone implemented this
... Might be interesting to consider just adding stuff. But I can see hwo deletions might be useful for other types of data
aaronpk: I don't remember doing that. I'm pretty sure I just talk about publishing simple feeds
<KevinMarks> we have done that with webmention
tantek: any other comments on PuSH?
<KevinMarks> so could learn from that
KevinMarks: We have done some work on updates and deletes on lists of things with comments in webmention
... When there's a list of comments under something you can see which ones are new or which are deleted and update those
tantek: just updates or also deletes?
KevinMarks: In the case where you'r etrying to propagate comments through salmentions, you're implicitly responding to deletes there because you're propagating deletes. I think edits work better than deletes at the moment. Not sure
... There's an issue with assumed deletes because the classic feed is the most recent n items. Don't want to misidentify something falling off the bottom of a feed as a delete
tantek: aaronpk will look into it, and julien said there's a mechanism with tombstones in atom that could be used
... There are some concepts but nothing concrete. We'll let folks go off and figure that out and come back
Webmention issues
aaronpk: two I want to bring up
<aaronpk> https://github.com/w3c/webmention/issues/57
aaronpk: One I have a proposal in mind for, issue 57, response body in the webmention
... Right now it says the response may contain content and suggests a human readable response
<cwebber2> I have to go
<cwebber2> later, everyone
aaronpk: that response is just for the post request that sends the webmention
... THe intent is that that response is only ever visible to developers
... So similarly to how we address with micropub, I propose we add clarification that indicates that this is text useful to the client developer and not meant to be visible to end users
... In doing so, that removes the need for explicit content language or other meta information about that text
r12a: So if I understand correctly what we're saying is that these messages will be in English because we assume that all the developers will speak English
aaronpk: I was not going to recommend any language for the message
... It depends who is creating the app and who the expected developers are
... Most of the time this text is never seen
... It is only seen the first time somebody interacts with sending a webmention for the first time
... I would like to clarify that it's for developers and intentionally not recommend any language
r12a: this is Addison's comment so don't want to speak for him. He would probably have some concern because we should probably assume that developers might be chinese or japanese and if they want to use messages in those languages you want to know which one it is so you can use the right font, and of course if they use hebrew or something like that you're going to have a problem. I'm guessing that th ei18n wg would not stop us moving forward on that, but might
still be an issue
aaronpk: Is including a content language header a sufficent mechanism because that's already part of http? doesn't require special handling for webmention
r12a: gets us most of the way for language, doesn't help with direction
aaronpk: I'm curious to hear your other comments about text direction, because from what I read it appears unicode solves it
r12a: in this case it might be less of a problem than in the other cases, if you're dealing with a set of predefined messages, is that the case?
aaronpk: Not necessarily predefined. Not by the spec, likely predefined by the implementation
r12a: that's probably more manageable
... So you need to get a reply from Addison, maybe we can discuss that on thursday as well if we have time
... I'm not reaching any conclusions because this is Addison Philipps' comment, I was just exploring the situation.
... My thinking is if we can use content language headers and control codes in this particular case, it's probably more manageable than the general case we're going to talk about in a moment
tantek: let's get that recorded as a likely direction forward
... for this issue
... this is just for error messages right?
aaronpk: also success
tantek: can you record this as an issue pending resolution with the issue filer?
r12a: please check with Addison. I wouldn't like to say that what I'm proposing is a resolution
tantek: We'll leave it open pending that discussion
... aaronpk perhaps you can capture what r12a has said, or richard you can add it yourself to the issue
<Zakim> KevinMarks, you wanted to say can we refer to http for this?
KevinMarks: Can we just refer to http normatively for this? It says how to show error messages and what headers. We're not doing anything special here
tantek: Can you provide that citation for where in http it says how to show error messages, we can evaluate that
<KevinMarks> https://tools.ietf.org/html/rfc7231#section-6.5
tantek: Richard, do you know of any existing specs that are doing what is requested in the issue?
r12a: personally no. Addison might
... One of the reasons I'm reluctant to come on too strong here is because I haven't actually reviewed webmention in detail, Addison did that
tantek: to make more progress we need to involve Addison directly. aaronpk you have your additional actions?
aaronpk: yes
<aaronpk> https://github.com/w3c/webmention/issues/60
aaronpk: One more wm issue, 60
... the suggestion here is that because the webmention payload is sent using form-encoded request to copy the text from html5 that is strongly worded warning about the issues of form-encoded format itself
... THe suggestion is to copy that paragraph into webmention
... I think that's not a good idea, as the html5 spec is already normatively referenced by webmention
... I propose closing this without taking the suggested action
<rhiaro> THe proposal was not to copy paste text
scribe: just mention it
akuckartz: I agree, it was not the proposal to quote the text, just to refer to it
... My proposal would be to add a reference
aaronpk: my argument against referencing it is that webmention is using it as a transport, not talking about how to do form-encoding or decoding. The analogus version of this for any spec that uses json is that you would never find, say in AS2, text that describes how to parse a json string
... People understand that you refer to the json spec to understand how to parse a json string
... I don't think there's a need to point out the downsides of using json over any other formats, for example
tantek: this issue is marked editorial, so regardless of how it is resovled there's no impact on implementations?
aaronpk: That's correct
<KevinMarks> it already references HTML5 explictly, though not linking to the form encoding section
tantek: akuckartz, is there a particular reason you think this particular detail needs to be referenced beyond the overall reference to form-encoding?
akuckartz: when you implement everything you have to deal with the issue raised in this text. If you use a library you will not encounter this probably. I think it's editorial, not one that's absolutely necessary
tantek: Since it's purely editorial and it sounds like there aren't strong feelings, I'm going to propose to go with the editor's preference
<tantek> PROPOSED: resolve webmention issue 60 as editorial with action (or lack thereof) at editor's discretion.
<annbass> +1
<KevinMarks> +1
<aaronpk> +1
<akuckartz> +1
+0
<sandro> +0
<eprodrom_> +1
RESOLUTION: resolve webmention issue 60 as editorial with action (or lack thereof) at editor's discretion.
i18n issues in AS2
tantek: only 5 minutes left but let's get started so we can follow up on Thursday
r12a: My aim is to set the ground for THursday, you'rea ll invited to come to the i18n teleconference
... I want to explain some things about how i18n review works and answer any immediate questions
<KevinMarks> could link wm directly to https://www.w3.org/TR/html5/forms.html#url-encoded-form-data rather than the html5 spec as a whole?
r12a: I have to explain that in i18n we don't know everything about everything, fairly obvious but people sort of seem to expect that we do. We have specialisations, my specialisation is not JSON or technologies realted to that. Addison and Felix know more about that
... I've been trying to learn what I can about the technology recently and we're trying to get together recommendations that are much more focused on the technology that will help you and other groups working with JSON in the future
<r12a> It must be possible to indicate base direction for each individual paragraph-level item of natural language text that will be read by someone.
<r12a> It must be possible to indicate base direction for embedded runs of inline bidirectional text for all natural language text that will be read by someone.
<r12a> Annotating right-to-left text must require the minimum amount of effort for people who work natively with right-to-left scripts.
r12a: There are millions upon millions of people using rtl scripts
<r12a> https://github.com/w3c/i18n-activity/wiki/Specs-handling-text-direction
r12a: This is an unoffical draft wiki page with concerns noted about the approach. One issue about being able to put markup in place for the name property
... But I'm focussing here on getting text direction adequately specified
... If you go to that page I've sketched out what I think is the current solution proposed by the socialwg
... It ocnsists of putitng in control chars at the beginning and the end of paragraphs that don't support markup, and putting in markup for summary and content paragraphs
... Typically that is something that you can do to describe direction, but my understanding is that a lot of these messages, this text will be created by users. We expect there to be a problem in this case, because in many cases users would find it redundant to provide these control characters, if they're typing into a form in a webpage for example
... They may use the keyboard, or rely on an inherited direction in html
... They may not have a keyboard that lets them type control characters
... And even if they could to put in this extra information for every string they type in is really not going to work
... So we're exploring alternative ways of doing that
... I've put alternative suggestions on the wiki page
... A new property called direction is something we did for web annotation for text direction
... Only when you have the odd occasion that the text content is unusual do you have to step in and do something else
... That's something we'd like you to consider
... I'm also in the process of putting together a much more detailed discussion of the issues
... We're putting together more specific guidelines for people using JSON and JSON-LD
... There are problems with both in terms of catering for direction
... We will at some point go back to the JSON-LD guys and say is there a better way of doing this. We want to make sure we have a workable system for all those millinos of peoplle who use rtl scripts
... When you publish AS2, or at the very least recognise if it's not going to service these people the way we'd like it to
tantek: we have a queue and we've gone over, but since r12a I'd like to suggest we extend our call 15 mins if Richard has time
r12a: fine by me
aaronpk: Have you looked at existing apis not w3c apis, such as facebook or twitter or other social networks that exist only in particular countries that have rtl scripts, and figured out how they handle this issue? It seems like there are primarily Asian social network apps that have almost exclusively Asian users and they seem to be working fine. I'm curious to know if you've research how they've solved this
r12a: I don't have a lot of informationa bout that, I have spoken with twitter at one point but I have to admit that I don't know if my information is now up to date. I don't know the asnwer to that but it's certainly something I can look into
... I guess the thing we're concerned with is that you're describing a model here which we hope iwll be generic and will therefore carry the metadata that is necessary for realising and using text appropriately
aaronpk: I understand the concern. My concern is that so far we havne't seen any suggestions based on implementations. These seem like possible technical solutions to the problem, and I'm mostly curious to see if these suggestsion come from how people are solving this today
r12a: That's something we can look into
aaronpk: I would love if you guys did some research on that and came back and say 'here is a survey of the 12 apps we analysed and how they handled this issue'
r12a: bearing in mind also that we don't understand your technology very well, we were asked to review AS2, we don't know much about it. We don't have the bandwidth know everything about everything. So we rely on you to help with the solutions. We try to focus on what the requriments are and try to understand with you how you think those requirements can be met
aaronpk: I get that. The thing that would be the most helpful for me is that because you have more experience with this issue, getting the real world background of existing implementations, describing how they solved it, as ane ditor I can look at that and see how that applies to my spec
... You're in a better position to understan dhow existing APIs are solving it because you're more familar with this space
r12a: okay
<Zakim> tantek, you wanted to ask general question (again) of are there any existing (deployed) specifications (JSON-based) that follow these guidelines? or is this all new?
<KevinMarks> https://blog.twitter.com/2012/right-to-left-languages-on-twitter
tantek: There is a workable system today for the millions who use rtl scrpts, they use a number of social media applications. Develoeprs that are writing applications for them.. so there is some sort of existence proof there that the market has somehow solved that problem
... There is something workable, it's just proprietary. Our goal is to make something workable that's standard
... Rather than trying to reinvent what's workable
... Which is why we have the questions about real world examples
... In particular I'm going to generalise to are there any existing deployed specs that are json-based, not specific to AS2 or micropub or anything in socialwg, but rather json as a whole, that follows these guidelines that you've provided, or are all of these guidelines kind of new and we are no in the process of trying to upgrade how json specifications are done?
r12a: This is not something that the i18n working group has al ot of experience in, we're trying to learn as we go
... We've been through one cycle with web annotation and developed a solution with them for their json based stuff
... Felix has a lot more experience with this, but also more despair about whether these things really do work
... He comes across problems a lot
... I wonder sometimes how effective existing solutiosn are
... In Oman recently I asked what they were using and the range of stuff they actually use is very limited because of the direction problem
... Things like photoshop and adobe products, things of that kind, powerpoint
... They were really struggling
<KevinMarks> https://facebook.github.io/draft-js/docs/advanced-topics-text-direction.html
r12a: The world doesn' tknow a lot of the time how much they're struggling
... I don't know if they're struggling with facebook, twitter. I would be interested in looking closely to see if they're really doing as well as they need to
... Even with html recently there have been problems in really properly representing rtl scripts, so I'm not denying these users, but saying let's be a little cautions and look into it. It might not be as rosy as we hope.
tantek: I don't think anyone is saying it's rosy, but you used the word workable, seems like a reasonable bar
<csarven> dokieli is deployed.
tantek: Par tof the concern here, and annotations is an example here, is that there is nothing deployed that follows these guidelines
... These recommendations should be based on implementation experience, not base don aspirational technical requirements
<bigbluehat> I'll add that Wiley is implementing the Web Annotation Data Model for our publishing pipeline, and will be using the things the Web Annotation WG (with r12a's help) has put into that model
tantek: Web annotations has nothing that's widely deployed in rtl languages
... So it doesn't really count
... This probably isn't the only time you'll get these kinds of questioning
... not just for socialwg, but across w3c
r12a: let me go back then and say that what we do understand are the rquirements. We understand rtl and bidi scripts work
... We understand the problems with them, and the information you need to make them work right
... We don't want to design your spec for you, we want you to do that, we want to help you understand where there are likely to be problems
<akuckartz> r12a+
r12a: What I'm talking about is not aspirational, i'ts real world requirements that need to be supported by your specification
... And we need to understand how that's going to happen
tantek: this is about anything using json
... It's one thing to say we don't understand what you're doing with AS2, that's fair. But this is about anything using json, which goes far beyond AS2, far beyond socialwg, and beyond w3c
... The majority of APIs today with social networks are using json, therefore the assertion is that these apps are deployed with these apis with rtl languages with user adoption
... Something has happened there
... The reason I call it aspirational is that if we cannot point to a single json api standard that follows these rquiremeents then they're aspirational, they don't support requirements that exist today
r12a: I wonder if we mean the same things when we say requirements
aaronpk: This article from facebook does a great job at describing those requirements
... *reads section of article*
... From what I've seen, having read this doc about facebook, as well as the twitter documentation, seems like their solutions are detecting the primary direction of each block of text, as it's needed, rather than making it something the user enters or indicates themselves
... Part of the goal is to make it easy for users to enter, so they don't have to do anything
... We do agree on the requirements, that we need to support them and it should be easy for users, however the aspiration parts of what we've seen from the recommendations from i18n is suggesting a particuarl way of handling it that has not been demonstrated as successful of anywhere else
... facebook and twitter seem to do the exact opposite of what you're suggesting
... They put the burden of detecting the language direction on the consumer of the api, not the publisher
... tha'ts the mismatch here
... We agree on the requirements but the best thing that the i18n group can do for these spec is to actually document what is working in the world righ tnow rather than making recommendations that have not been proven
r12a: we're not making recommendations yet. The wiki page i posted are not recommendations either, just suggestsion that we can talk about and decide if they work
... twitter use a first-strong approach, they looke for the first strong character in a string and there are certain exceptions. Works most of the time but not all of the time. To work all of the time you'd need a different approach.
... The things that are out there don't necessarily work correctly or as well as they could
... The wiki page I linked are just suggestions of things to consider, not intended to say this is what you should be doing
... One of those suggestison actually does involve the use of first strong detection that they're using int witter
... There are a number of alternatives
<tantek> "as well as they could" seems a very different bar from "workable", and that concerns me
<tantek> (vis-a-vis perfect enemy of the good etc.)
aaronpk: I guess what I'd like to see along with these suggestsions is evidence that theyr'e based on real world implementations. I can't tell if they are from reading the page
... That's how I'd be more comfortable with evaluating a possible solution for one of my specs
r12a: right
<Zakim> KevinMarks, you wanted to point to https://blog.twitter.com/2012/right-to-left-languages-on-twitter
KevinMarks: in the twitter post, it seems like most of the work si on the input side, they're inserting the rtl markers in the strings, they generate useful utf8 code on the input side
<bigbluehat> aaronpk: Draft.js which KevinMarks linked to uses a single `textDirection` property with values of 'left', 'right', and 'center' for storing text direction...it doesn't exactly differ from what Web Annotation is doing as I've pointed out here https://github.com/w3c/activitystreams/issues/338#issuecomment-235384311
KevinMarks: I don't think we have a representation problem. We need guidelines on how to generate these things... not in scope for the representation, more of a user experince thing
<KevinMarks> I think the twitter example is stronger than the fb one
tantek: richard, do you have an understanding of this wg's concerns?
<aaronpk> bigbluehat, that section is prefaced by "it is *also* possible for engineers to manually set the text alignment for an editor's contents."
r12a: I'll reiterate my hope that you also look for these things, rather than just leaving it to us to understand these apis. Certainly it's something we can all do
tantek: good shared responsibility
... anything else?
<bigbluehat> aaronpk: point being that there's nothing terrible magical or strange about storing a text direction value in a property...
<KevinMarks> right, but it is making the monolingual assumption
<bigbluehat> I'd also encourage everyone to look beyond just the social networking snow flake APIs. Publishing, education, and science have all been dealing with these issues far longer and have far more to teach.
<bigbluehat> KevinMarks: you can store language also
<rhiaro> I'll put up an agenda for unofficial editor's calls for next couple of weeks
<akuckartz> bigbluehat++
<Loqi> bigbluehat has 4 karma (2 in this channel)
tantek: eprodrom, anything about AS2 before we close?
<akuckartz> r12a++
<Loqi> r12a has 1 karma
eprodrom: We'll be on the i18n call on thursday, we canhopefully resolve then
<bigbluehat> KevinMarks: http://w3c.github.io/web-annotation/model/wd2/#h-external-web-resources
<r12a> https://lists.w3.org/Archives/Member/member-i18n-core/2016Aug/0001.html
<Loqi> [Robert Sanderson] Web Annotation Data Model
<bigbluehat> there's format, language, processingLanguage, and textDirection--which should cover most if not all scenarios
<r12a> ==WHERE ==
<r12a> Tel: +1-617-324-0000 (Webex)
<r12a> https://mit.webex.com/mit/j.php?MTID=m78201e27974c03949e089c11e487a449
<r12a> Meeting number: 310 818 734
<r12a> Meeting password: i18n
<r12a> IRC channel: #i18n on irc.w3.org:6667
<r12a> IRC via the Web: http://www.w3.org/2001/01/cgi-irc (#i18n channel)
<r12a> Details: https://www.w3.org/International/wiki/Core_Homework#How_To_Dial_In
<bigbluehat> tantek: depends on your definition of deployed. :)
<aaronpk> time?
<bigbluehat> all the things published by Wiley in our publishing chain?
<bigbluehat> does that count?
<r12a> == WHEN ==
<r12a> Time: 15:00 UTC <---- Note time UTC
<r12a> http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160721T1500
<KevinMarks> "exactly 1 language" and " exactly 1 textDirection" is a strange constraint
<KevinMarks> you have textDirection and separate rtl and ltr properties?
<KevinMarks> how does that work?
<KevinMarks> @bigbluehat
public-socialweb@w3.org
r12a ^
<bigbluehat> KevinMarks: no, ltr, rtl, and auto are values of textDirection
<sandro> https://lists.w3.org/Archives/Public/public-socialweb/
<tantek> Dial In Number: +1-617-324-0000, Access code: 640 626 095 - for Thursday i18n call
<bigbluehat> KevinMarks: and how would propose to handle more than one language and more than one textDirection for a single string?
<annbass> thanks for scribing rhiaro, and for chairing tantek! thanks to all for trying to think about other people in the world (i.e., i18n issues)
<KevinMarks> html defines it
<KevinMarks> unicode defines direction markers inline
tantek: unofficical calls coming up, then next official call on 23rd
<tantek> Arnaud: can you confirm you can chair 2016-08-23?
tantek: Thanks everyone
<akuckartz> i18n++
<Loqi> i18n has 0 karma (1 in this channel)
<tantek> rhiaro++ for minutes!
<Loqi> rhiaro has 232 karma (122 in this channel)
<bigbluehat> rhiaro++
<Loqi> rhiaro has 233 karma (123 in this channel)
<KevinMarks> you allow multiple languages, which is good, but not multiple text directiosn which is odd
<KevinMarks> so I can mix hebrew and arabic, but not arabic and french?
<tantek> r12a++ thank you for all your participation (especially going overtime) in our telcon!
<Loqi> r12a has 2 karma
<bigbluehat> KevinMarks: that's why there's a language *and* a processingLanguage
<tantek> trackbot, end meeting