W3C Web API TPAC 2015 Breakout session

28 Oct 2015

See also: IRC log


Vivien, Antonio, Ted, David Clarke and 2 others (likely junichi-hashimoto and mkaki based on the IRC users present)
Jean-Gui, Denis


vivien: Hello and welcome
... Why the need for this data from W3C?
... people will be able to build more things with this data; and also it's data we want to give back to the community
... It's a public API; tested in the last weeks/months.
... It returns data in JSON format; ready to test at api-test.w3.org.
... Follow our project on GH; we keep track of issues there
... The code itself is *not* on GH; as it's closely related to some of our internal tools

vivien: You can get info about specs, groups, orgs and users right now
... You can get information from, eg invited experts, and all users who are participating in WGs
... http://www.w3.org/2015/10/web-api-tpac/?full#api-sample
... here's a simple example: the HTML5 spec

[vivien going through all the properties/fields on the slide]

vivien: Among other things, we have links to related versions of a spec, eg previous version


vivien: You can create your personal API keys from your W3C user profile page
... keys can be revoked, regenerated, etc. Also, they may or may not be associated to a specific origin.


[vivien showing an example of real JSON returned by the API, and following links to new pieces of information]

[vivien following some of the links on http://www.w3.org/2015/10/web-api-tpac/?full#4 ]

Example of a group info

vivien: name of the group, its type, list of chairs, team contacts, participants...
... info about the charter(s) of the group: extension, IPP, URL to join the group...


vivien: Domains: page of the domain, groups it "contains", resources (repos, channels, lists)...


vivien: Organisation: home page, participants (info that is already publicly available) groups that this company is involved on...

DavidClarke: does this allow "join" queries, eg participants of group X who are also in group Y?

vivien: Let's talk about that later


vivien: Two options for authenticating users of the API.


vivien: we have pagination, to avoid answers that are too long
... More about all this on the GH site.
... Coming back to David Clarke's question...
... right now, you'd have to make 2 queries, and then merge the results.
... For the i18n group, for example, you get a list of participants, each with a URL with details
... if you were to follow those links, that would be already ~76 requests.
... To avoid that, and to get more information from just one request, we have the "embed" parameter
... Also, the pagination might help to reduce the # of requests.
... The API is JSON, so probably you want something else on top of that
... We have written Apiary for that


vivien: It's a declarative JavaScript library; the project is on GH.


vivien: we specify our API key, and the ID of the (group|domain|user|whatever) we need...
... then put "placeholders" where we need the actual data.


vivien: This example shows how to use Apiary to populate info about a particular domain...
... on this page, the list of activities, with links, comes from the API.
... On GH you have a link to the API documentation: parameters, how to use the keys...
... Some people are already using the API in the real world.
... For example, GH contributions may be checked against the ID of the committer, using the API.

DavidClarke: I haven't seen info about translations, eg of specs.

ted: We don't have info about those translations.

DavidClarke: By definition, the i18n WG has a lot of material translated. If my preferred language were, eg, Japanese, I might want that if it's available.

vivien: All this info is coming from our DB; all that I've shown now -- we only have the English version; no translations.
... as far as the DB is concerned, there's only English.

DavidClarke: Too often, we present the English version and expect that to be "good enough" [for all users].

ted: I'm not against i18n, but this is an early version and...

DavidClarke: I'm fully aware. I'm saying it's easier to embed support for i18n at this early stage, as opposed to doing that later.

vivien: I'll have to look at how to do that in JSON. Any pointers?

DavidClarke: BCP-45...? BCP-64...?

vivien: Not those ones; if you could send that to us later.
... Who would be the best person as a contact in the i18n WG?

DavidClarke: r12a.
... I come across so many projects where encoding and language were not taking into account from the beginning.

DavidClarke: So we don't have info about languages in the DB?

vivien: no that I'm aware of. There might be some, but we assume it's English.

ted: We'll need to keep that information, because... well, machine translation isn't good.
... We get people who enter their name localised, using non-English chars, etc.
... What would be the right way to deal with those cases?

[DavidClarke going through various examples of person names that are difficult to infer, in terms of language.]

[David & Vivien looking at some localised testimonials from members; there we do know the language...]

[Vivien & David discussing the benefits of i18n in relation with the API]

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/11/04 08:00:23 $