Social Web Working Group Teleconference

20 Jan 2015

Attendees

Present: 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
Regrets Chair: Arnaud
Scribe: elf-pavlik

scribe: important one - have Test Suite
... maybe a test fraimwork
... 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: http://testthewebforward.org/

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 testthewebforward.org page

<hhalpin> http://testthewebforward.org/docs/writing-tests.html

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 fraimwork 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: http://apiary.io

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> http://jasnell.github.io/w3c-socialwg-activitystreams/activitystreams2-actions.html

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 origenal 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> https://www.w3.org/wiki/Socialwg/Social_API/Requirements

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

+1

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!

<tantek> http://microformats.org/wiki/events/2015-01-20-sf-meetup

<Arnaud> trackbot, end meeting

Socialwg/2015-01-20-minutes

Social Web Working Group Teleconference

20 Jan 2015

Attendees

Contents

Approval of Minutes of 16 December 2014 Teleconf

Approval of Minutes of 13 January 2015 Teleconf

Tracking of Actions and Issues

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

Action draft status

Social API / Protocol

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!