From W3C Wiki
Jump to: navigation, search

Social Web Working Group Teleconference

20 Jan 2015


See also: IRC log


jasnell, elf-pavlik, +1.314.777.aaaa, aaronpk, Arnaud, AdamB, wilkie, bblfish, Ann, +1.514.554.aacc, eprodrom, cwebber2, Wendy, KevinMarks, Lloyd_Fassett, Bill_Looby, tantek, Sandro, dromasca, jessica_lily, hhalpin


<trackbot> Date: 20 January 2015

<Arnaud> elf, you're jumping the gun :)

<cwebber2> hello

<cwebber2> -q

<eprodrom> AUGH

<cwebber2> -q ??P12

<cwebber2> horray, dialed in.

<KevinMarks> that's me

<Loqi> tantek: elf-pavlik left you a message on 1/18 at 2:40pm: that rhiario suggested: indiefriends list could come useful for vouch

i could scribe

<tantek> elf-pavlik: have you or rhiaro implemented vouch? how do you know it would be useful? just hypothesis?

<AnnB> +1 on thanks to elf!

<wilkie> elf-pavlik++

<Loqi> elf-pavlik has 3 karma

<cwebber2> thx elf-pavlik :)

<scribe> scribenick: elf-pavlik

<wilkie> I can scribe next week. put me on the queue or what-have-you

<rhiaro> tantek: not yet (I know, I know), but I understand from the wiki that there needs to be some kind of discovery of trusted people for vouch to work?

Approval of Minutes of 16 December 2014 Teleconf

<eprodrom> +1


<wilkie> +1

Arnaud: any objections?

<tantek> fixed heading

Approval of Minutes of 13 January 2015 Teleconf


Arnaud: any objections?
... approved

<eprodrom> +1

<eprodrom> Whew!

Arnaud: minutes tentative until approved

<eprodrom> Me!

<bblfish> ok, my connection is very likely to break every 10 minutes

Arnaud: next week chair eprodrom

<tantek> handy pro-tip: chair rotation is alphabetical by given name :)

Arnaud: Jan 27th

Tracking of Actions and Issues



<wilkie> tantek++

<Loqi> tantek has 141 karma

eprodrom: dates for milestones month & year instead of exact day


eprodrom: fewer fine grained milesontes
... easier for us to stay more flexible with it

Arnaud: thank you Evan for doing it
... close actions 23 and 24


Arnaud: will no go one by one, anyone has updates on any of them?
... any actions open for which you have problem and you need some kind of support?

<jasnell> ACTION-27 is done. It's just waiting on the W3C staff. Expected publication is Thursday

Arnaud: anything that stops you from completing thos actions

<jasnell> ACTION-28 also

<tantek> Arnaud: or any action where you are waiting for something, you need something, you need help from someone

<jessica_lily> sorry i'm late all

eprodrom: on ACTION-25 expecting IG meeting tomorrow where we should have chance to address it
... we should continue to move forward with collecting requirements for Social API

<tantek> congrats AnnB!

Arnaud: for those not on IG - change of chairs Mark needed to step down and Ann volounteered, still looking for co-chair!
... please step up if you would like to get some experience

AnnB: also waiting for approval from new boss, especially in relation to travel
... would like support from elf as background co-chair
... happy to hold those meetings even before formalized

jasnell: ACTION-30 all content archived and can be made available for us if needed

<AnnB> re: chairing of SocialIG ... that is, if that arrangement is OK with elf

<Loqi> harry: rhiaro left you a message on 1/15 at 2:04pm: - improvements/bug reports welcome

jasnell: also following up on ACTION-29, please expect update next week

<harry> +1 just using the same channel

Arnaud: anyone else would like to declair victory?

<AnnB> +1 on same channel ... makes sense

tantek: harry said he will ask systeam to look into restoring OpenSocial blog, permalinks and content

<AnnB> the others in IG would have to agree

<bblfish_> action-31

<trackbot> action-31 -- Harry Halpin to Will ask w3c systeam about prospect for archiving osf blog posts and perhaps other content -- due 2015-01-20 -- OPEN


<harry> sysreq request filed

<jasnell> 30 is closed, 31 is still open

<harry> but no response yet

AnnB, please count on me in IG ! :)

<jasnell> we'll need access to the archived content in order to complete 31

Arnaud: closing 27, 28 and 30

<AnnB> a deep bow of gratitude to elf

Arnaud: thank you!
... no new raised issues, we will need to tackle those open at some point
... we will need some product to organize issues better


Arnaud: please make proposals on how to address issues

<jasnell> there is backwards compatibility discussed in the current WD

<jasnell> I believe the current draft addresses #7

Arnaud: we should address them and officialy close
... so that we can move spec further

Activity Streams 2.0's path to Candidate Recommendation (CR)

<Zakim> tantek, you wanted to ask AnnB what she thinks of using #social for IG so we can all have the same logs etc. Just as we share f2f meeting venue and time.

tantek: about previous topic, question or request or pool

<harry> We probably want some more implementation experience before hitting Last Call.

tantek: to reconsider if then want to use #social IRC channel to share it with WG to improve cross polination, cross working

AnnB: makes a lot of sense

<harry> +1 it would simplify the situation, every call it's caused confusion :)

tantek: will put it forward as formal proposal

<AdamB> being a member of both i have no problems with that either,

<harry> Happy to file sysreq requests if we get consensus

jasnell: back on issues, ISSUE-7 current draft addresses it
... provides clear rules how to support pre JSON-LD syntax

Arnaud: I suggest to send email to the list with proposed resolution
... we can put it on a agenda on the next call
... please mark it as pending review

elf: i would prefer to move MediaObject for next week

Arnaud: please put it on next week agenda

<bblfish_> :-)

<jasnell> tantek: no worries.

<aaronpk> *whew* much better

Arnaud: just to highlight W3C process
... used to have stage callled Last Call

<harry> Note that we have a schedule:

Arnaud: we think we are done and now invite world to comment
... then CR after that

<harry> That has ActivityStreams going into Candidate Rec at Q4 2015

Arnaud: now process become simpler and combined it into single Candidate Recommendation

<harry> So you can just ignore LC part of the charter on web-page, although if we feel ambitious we can hit Q3 2015

Arnaud: spec republished as new draft
... in practice chairs will need to produce *transition request*
... chairs from other WG will get notifications


Arnaud: i put it on agenda ^

<jasnell> We need to determine what a "test suite" looks like for AS2

scribe: important one - have Test Suite
... maybe a test framework
... doesn't need to be complete at time of publishing the CR
... people who want to provide feedback on their implementations need to have test to check their work
... we also need to gather feedback on implementation work and experience
... as we go to CR we need to define as group criteria of declairing victory

<AnnB> OK

scribe: at least 2 implementations required and passing the test suite
... each feature needs *at leaset 2 implementations*

<jasnell> There are three aspects: (1) Syntax Production ... verify that an implementation produces valid AS2 (2) Syntax Consumption ... verify that an implementation is properly able to parse and understand all normative serialization and (3) Semantics ... make sure that an implementation properly understands the semantics of the data it's working with.

scribe: i had some talks with James about this and he has some ideas
... the easier we make it to people to implement and test their implemenations the better
... i hope people realize that it involves quite some of work
... i try to prepare you to step up and take on some of that work

<hhalpin> Note that we need at least *two* interoperable implementations but we really prefer more.

scribe: we need to *document implementation reports*

<hhalpin> At this stage, a wiki-page to keep track of implementations make sense, and we can start a test-suite on github.

scribe: we need workflow for collecting such reports

<hhalpin> See here for more info on testing:

scribe: we need to start thinking about what it will take to do all that

Arnaud: we need to claim that we had a wide review of the specification and decide if we have any features at risk
... i learned in the hard way in LDP WG
... as we move forward the specification gets more and more stable
... when we get to CR we say: save for you to implement and unless we find problem we will make no changes

<tantek> it's not that we think we're done, but rather, that we believe all outstanding issues have been resolved

Arnaud: safety valve - features at risk

<tantek> and that we're *ready* for implementer feedback. we know we're not done because we know that implementers *will* find issues while they implement, report them, and help improve the spec.

Arnaud: if we don't feel fully confident about some features we can mark them as *Feature at risk*

<jasnell> we could reasonably go through the various Classes in the Extended Vocabulary and mark those At Risk I think

<jasnell> there are many that are pretty stable

Arnaud: this way we can simply remove it and the rest of the spec can safely move forward

<jasnell> but there are some we'd likely need a bit more impl experience to prove out

Arnaud: otherwise it will require going again into cycle of CR
... once again i learned it the hard way
... we ended up with one feature which we didn't get implemented

<hhalpin> Actually, of more concern to me is that we don't have a FPWD of the API as well.

Arnaud: we have a lot of work to do and please take it as clear invitation to help

<jasnell> +1 :-)

Arnaud: jasnell took a lot of work and he could recive some help from the group

<Zakim> tantek, you wanted to mention how to help with test suite / test case contribution motivation. hint: everything starts "at risk".

<hhalpin> Ideally, as there may be dependencies, we didn't want for one to go to CR before the other.

tantek: first of all thank you Arnaud for this excellent overview
... in many WG and many draft for getting test suites for specs
... we can start with all features marked as *at risk*

<cwebber2> jasnell: I'm interested in helping, but I'll need help learning how to help ;)

tantek: this way people who care about them, will produce test case and implemenation

<KevinMarks> +1 to test-driven spec dev

tantek: this allows us the freedom to as a group to decide if we want to wait for tests and implementation for big number of features

<bblfish_> sounds interestnig the idea of a test driven spec

tantek: or smaller number of features and ship faster

<bblfish_> The only issue is how to write the tests, what would they look like

<hhalpin> bblfish, see the page


eprodrom: i feel concerend about testing process
... especially at this point, simple JSON-LD processor can consume AS2.0 content without any need to understand semantics underneath

<tantek> I share eprodrom's concern.

<tantek> Abstract data structure processing is not particularly interesting.

eprodrom: do we have best practices for testing data structures without an API recomendation?
... not clear what to do with AS2.0 on its own

<hhalpin> In general, we need the API to go to CR at same time at AS 2.0. See charter.

Arnaud: we need to clarify what exactly we test

<tantek> In regards to eprodrom's question, I'd like to see tests that show some *visibly* *distinctive* result for each type of AS object

<tantek> not just a code dump / pretty-print JSON

Arnaud: we need to develop test framework and explain to people how tests look like for people to contribute tests

bill_looby: question about *features*
... not clear how we define features
... do we want to tie down individual APIs and call them features?

jasnell: we have data format itself and the context it gets used in
... we can't test right now any of the behaviours
... for now we can for example make a validator
... similar as we did during work on ATOM format

<tantek> IMO a validator would be a nice implementation but not a sufficient implementation to exit CR

<tantek> it's too abstract

jasnell: in the long term, we could have set of valid and invalid AS2.0 documents
... once we get API defined then we can go back and create test suite together with context we use them

<tantek> TBH there is enough history and experience with AS that we should expect *presentational* results. Not just validator results.

<eprodrom> I like the validation angle

Arnaud: i didn't expect us to have answers to all those questions right away
... that's why i wanted to bring them up today
... we need to have an idea what we want to test
... we need to at least know where we go with it to move forward

tantek: given long history and experience with ActivityStreams we should go for a higher bar than just a validator or something that checks only syntax or data

<bblfish_> So it looks like mostly we would have a syntax validator as a test suite. But that does not seem to make it possible to have a number of people add to the test suite.

<jasnell> tantek: open to ideas on what that would look like absent an api :-)

<Loqi> sandro: ben_thatmustbeme left you a message on 1/15 at 2:13pm: looks like i'll be co-organizing IWC Cambridge 2015, can you confirm that we have a venue for those dates? 2015-03-19/20?

tantek: i know we don't have an API yet but don't think we need one

<aaronpk> +1 to the goal of actually presenting AS 2 data in a usable way

tantek: just to test various object types we work with
... let's raise the bar!

<jasnell> need to know what those higher expectations are

sandro: couple of thoughs

<jasnell> not arguing against it, just saying :-)

sandro: we don't need a test suite
... we need an evidence that spec has proper implementations

<tantek> jasnell: screenshots are a good start - of implementations showing different presentations of different object types

sandro: and agreement that they correctly implement the spec

<KevinMarks> possible tool:

sandro: test suite acts only as one of techniques to proove proper implementations
... on acting everyting as 'at risk' dosn't sound right to me

<bblfish_> Is there some interoperability requirements of activity streams 2.0

<bblfish_> ?

sandro: it should act as *highlighting* some features and would not come helpful for community
... we would make a really strong case to do it this way

<wilkie> it will be a challenge to capture testing the extensibility we should be promoting as a strength

<jasnell> is consistent UI presentation of an Activity Stream object a requirement? If it is, it's a new one. There have never been presentation requirements in AS

Arnaud: i understand it as makring everything what doesn't have tests marked as 'at risk'

sandro: i've seen specs with 2 or 3 features *at risk* but 5 and more sounds like bluring it all

<KevinMarks> right, but we have inherited a lot of speculative features from our inputs

Arnaud: I agree with sandro, test suite is only a means to an end
... test suite often makes it easier for poeple to test their implementation
... let's leave it for this week

<jasnell> to use UI presentation as a benchmark, we'll need someone to draft up a proposed set of UI requirements or guidelines

Action draft status

Arnaud: we have this document that James started developing

<tantek> jasnell - we need nothing so formal. Even just guidance about *different* presentation for different object types would be a good start.

Arnaud: i would like to know where we stand af of this document

<bblfish> which action draft URL?

<hhalpin> tantek - I'm wondering if there's some other analogous cases in other WGs.

<tantek> Because if two object types are treated the same in presentation, then it's evidence we don't need both.


jasnell: we have updated version of a draft which i have kept up to date with other document
... at this point would make sense to acknowledge if we want to work on ti

<tantek> The challenge here is that there's A LOT of different object types / etc. in AS - and that's been a longstanding weakness of AS (or challenge to implementers to try to understand it)

<tantek> "There are too many types, make fewer"

jasnell: we need a lot of implementaiton experience and to get more people looking at it

Arnaud: any comments?

<tantek> similar to the feedback given at the F2F about - do we really need verbs?

Arnaud: i would like to propose next week to consider publising it as FPWD

<eprodrom> +1

<tantek> answer: in practice, no.

<tantek> This is why we need a high bar for AS features for CR

<jasnell> +1

<hhalpin> Would be good to have some more discussion of it onlist beforehand.

Arnaud: we'll put it as fromal proposal for next week, please prepare to take a position on this

jasnell: please take a look at editor draft

<KevinMarks> the original AS process was in effect a Union of features in existing platforms

Social API / Protocol

<tantek> sees XSD in actions spec - yikes - people still use XSD?!?

<jasnell> elf-pavlik: already posted it above

Arnaud: i want to make sure we on the same page

<KevinMarks> interop requirement means redefining it as an Intersection

<jasnell> tantek: XSD used for typing, It's in JSON-LD too. Wouldn't get hung up on that

Arnaud: we had very extensive activity going over various social APIs out there
... trying to educate ourselves
... now how we go from there to have a draft

<tantek> jasnell - yeah it's quite heavyweight - for both.

<jasnell> tantek: I have no problems marking specific classes in the vocabulary as At Risk until impls prove them out more

<hhalpin> Well, we need an editor :)

Arnaud: email from harry puzzled me announcing first draft before next F2F meeting

<tantek> jasnell - I'd say mark all types at risk until we have test cases for them.

<jasnell> we rely on it solely for the data type identifiers

<eprodrom> +q

<eprodrom> Sorry, I thought I was speaking next

bill_looby: i implemented AS withing Connections product
... if i have long list of requried features, product featues, structural features

<tantek> bill_looby: for each feature you feel is "required", could you commit to providing a test case?

bill_looby: i don't want to fill the wiki with lots of useless text
... interesting question from tantek about providing a test cases
... we could provide it for some of features we already implemented

<KevinMarks> +q

<tantek> sounds like a good split then

<tantek> I'd rather get to REC sooner with a smaller real-world shipping spec

eprodrom: glad to have you here!
... we hope for presentation of connections product

<tantek> +1 on a review of Connections

eprodrom: especially review of your API

bill_looby: on conference next week, but could do it week after that


eprodrom: we should try to collect functionality out of those reviews


scribe: we started last fall but we should update it
... one of the big new things that came out - game mechanics, enterprise activities
... i'd love to get to provisional tumbs up/down on this list of requirements
... so that we can start soliciting some requirements for the API
... please *go over those requirements*, start conversation around them
... so next week we can decide on those requirements

<bill_looby> just as a note - I can add a lot of text to those requirements

KevinMarks: AS tried to be union of all this stuff while currently in W3C i see it more as intersection

<jasnell> bill_looby: +1

<tantek> +1 to spec'ing intersection, not union

Arnaud: the discussion will continue

<bill_looby> if there is any format restrictions/suggestions let me know

<bblfish> thanks

Arnaud: thank all for joining today

<wilkie> thanks all

<hhalpin> +1

<tantek> aside: microformats2 dev meetup tonight in SF

thanks Arnaud!

<AnnB> thanks Arnaud!


<Arnaud> trackbot, end meeting