See also: IRC log
<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)
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
<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
UNKNOWN_SPEAKER: eprodrom?
<sandro> eprodrom...?
<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
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
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.
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
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found ScribeNick: rhiaro Inferring Scribes: rhiaro Default Present: akuckartz, rhiaro, cwebber, aaronpk, dmitriz, tsyesika, annbass, KevinMarks, r12a, eprodrom, julien Present: akuckartz rhiaro cwebber aaronpk dmitriz tsyesika annbass KevinMarks r12a eprodrom julien WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 02 Aug 2016 Guessing minutes URL: http://www.w3.org/2016/08/02-social-minutes.html People with action items:[End of scribe.perl diagnostic output]