r12aaaronpk, the i18n wg is discussing this at the moment and trying to come up with recommendations that should apply to micropub, webmention and activitystreams (and webshare)
rhiaro... 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
rhiaro... 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
rhiaroaaronpk: 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
rhiarotantek: 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
rhiaro... 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
rhiaro... 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
rhiarotantek: 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
rhiarosandro: 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
rhiarosandro: 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
rhiaro... 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
rhiaro... 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
rhiarosandro: 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
rhiarojulien: 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
rhiarosandro: 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
rhiaroaaronpk: 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
rhiaro... 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
rhiaro... 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
rhiarotantek: 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
rhiarosandro: 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
rhiarosandro: 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
rhiarotantek: 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
rhiarotantek: 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
rhiaroKevinMarks: 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
rhiaro... 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
rhiarotantek: 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
rhiaroKevinMarks: 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
rhiaro... 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
rhiaro... 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
rhiaror12a: 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
rhiaror12a: 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
rhiaroaaronpk: Is including a content language header a sufficent mechanism because that's already part of http? doesn't require special handling for webmention
rhiaro... 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
rhiaroKevinMarks: 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
rhiaro... 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
rhiaroaaronpk: 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
rhiarotantek: akuckartz, is there a particular reason you think this particular detail needs to be referenced beyond the overall reference to form-encoding?
rhiaroakuckartz: 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
rhiaro... 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
rhiaro... 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
r12aIt 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.
rhiaro... 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
rhiaro... 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
rhiaro... 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
tantekq+ to ask general question (again) of are there any existing (deployed) specifications (JSON-based) that follow these guidelines? or is this all new?
rhiaro... 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
rhiaroaaronpk: 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
rhiaror12a: 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
rhiaro... 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
rhiaroaaronpk: 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
rhiaroaaronpk: 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'
rhiaror12a: 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
rhiaroaaronpk: 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
Zakimtantek, 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?
rhiarotantek: 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
rhiaro... 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?
rhiaro... 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
rhiaro... 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.
bigbluehatI'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
rhiaro... 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
rhiaro... 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
rhiaro... 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
rhiaro... 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
rhiaro... 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
rhiaro... 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
rhiaror12a: 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
rhiaro... 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.
rhiaroaaronpk: 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
rhiaroKevinMarks: 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
rhiaro... 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
rhiaror12a: 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
bigbluehatI'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.
tantekbigbluehat link to a JSON spec that uses such technique, then links to examples of real world use in the wild. without links, does not count, no.
tantekbigbluehat: and the larger problem is, if the assertion is that any user visible string cannot "just" be UTF8, but requires all kinds of side-properties, then you're gonna have a bad day
tantekbigbluehat: nope, I consider it highly suspect if you want to change how user visible strings are handled across all programming languages, frameworks, applications etc.
tantekbigbluehat: everywhere that "just a UTF-8 string" doesn't work, is going to have a problem with convincing the surrounding environment to a. carry sideband data, b. do so reliably (without false template data, or fragile loss from translations / corruption / filtering)
tantekthat's not how you make a brighter future. if you really want a brighter future, prototype it first, show that you have (links), THEN make your specs accordingly
Loqi[tantek] bigbluehat: everywhere that "just a UTF-8 string" doesn't work, is going to have a problem with convincing the surrounding environment to a. carry sideband data, b. do so reliably (without false template data, or fragile loss from translations / corr...
tantekbigbluehat: you are wrong asserting Facebook Twitter are "large enough not to care". They are large enough, globally, because they do care, in ways that matter
r12ainteresting, i just tried four straightforward test cases in twitter and they all dismally failed to produce readable results - perhaps i'll post those somewhere after i've done some more checking
r12aok, i didn't send the tweets - i can do that, but i need to explain what the results should have been too - i'm thinking of a page somewhere that shows what's expected and what's rendered
tantekaaronpk: did Loqi get it right to IRC, then did it make it ok to the logs, then did the logs serve them right, then did people's IRC clients get it right?
tantekaaronpk: right. There are those that say it cannot be done. Then there are those that go ahead and do it anyway. Guess which ones actually move the world forward towards a brighter future?
aaronpkfor the cases when automatic direction detection gets it wrong, the only way to solve it is to get user input. how you represent that user input is not relevant to that fact.
aaronpkinstead of taking the user input and putting it in a side channel, the system could instead embed the appropriate text direction characters in the string itself
tantekthe markup is already there in the context of authoring, thus adding the "lang" and "dir" attributes goes along with and *in* the existing "syntax" rather than being completely "on the side" / "out of band"
tantekso it's weird to see suggestions attempting to carryover the dir and lang attributes from a context where they make sense to a completely different context
tantek in case anyone wants to review quickly before the call: https://www.w3.org/wiki/Socialwg/2016-07-26-minutes
r12a hi Tantek ! :)
aaronpk r12a: I never heard back from you on https://github.com/w3c/Micropub/issues/37#issuecomment-235353560 I'm super curious if that works. I read up a lot on unicode RTL encoding last week.
rhiaro melvster: add regrets to the regrets section in the agenda https://www.w3.org/wiki/Socialwg/2016-08-02
RRSAgent logging to http://www.w3.org/2016/08/02-social-irc
KevinMarks present+
ben_thatmustbeme just pulled his head out of work stuff to realize he missed the call... and lunch
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
Zakim KevinMarks, you wanted to point to https://blog.twitter.com/2012/right-to-left-languages-on-twitter
Loqi [@Alwaleed_Talal] Giving humanity via @alwaleed_philan regardless of race & religion http://www.theworldin.com/article/10497/giving-it-all-away?fsrc=scn/tw/te/bl/ed/givingitallaway هبتي للانسانية بلا عنصرية https://pbs.twimg.com/media/CWh9I2aWoAEHWK4.jpg