- DRAFT -

Social Web Working Group Teleconference

20 Oct 2015

Attendees

Present: Arnaud, csarven, rhiaro, aaronpk, shanehudson, sandro, elf-pavlik, kevinmarks, wilkie, eprodrom, jasnell, ben_thatmustbeme, cwebber, tantek, hhalpin, james, tsyesika
Regrets Chair: SV_MEETING_CHAIR
Scribe: aaronpk

tantek: 9 people registered right now, i'd prefer if we could get everyone in the group especially everyone on the telcon to add their names
... either confirm, add regrets, or if you think you might be able to attend, add yourself still and add a caveat note
... that lets the organizer know that's a possibility, but if you might be able to attend please add anote
... if you're for sure not able to attend, add yourself to remote if possible, or add yourself to regrets

next week telcon

tantek: cancelling next week's telcon since it's during TPAC
... the next telcon will be Nov 3rd
... chair will be Arnaud

Arnaud: i can do that

tantek: great okay

WebEx vs Mumble

tantek: sandro has an update

sandro: we ended things last week was several people pointed out we have a mandate to make our telcon system inclusive, which requires plain telephone dialin
... so mumble is off the table, but if people want something other than webex, suggest alternatives

<cwebber2> sandro: does that include dial-in internationally? :)

sandro: but it has to have at least the same functionlity, at least dial-in

<tsyesika> cwebber2++

sandro: we can close this for now, but someone can prototype with others in the group if they want

tantek: for now, this issue is closed since Mumble doesn't have POTS support

<cwebber2> because international ability to dial in also seems a broadly accessible issue to me

tantek: if there is a counterproposal then we're open to hearing that

Agenda format

<sandro> cwebber2, *free* dialin isn't a requreiment, but it sure would be nice.

tantek: we had a clustered format of the agenda by topic
... there wa sa proposal to switch it to a flat FIFO agenda so that when items are added we get to everything rather than potentially getting stuck on the first cluster

<hhalpin> However, I agree with cwebber2 that we should have free dial-in and dial-in that is compatible with open-source/free software.

tantek: .there was an objection from evan, but then they talked, and now evan is not objecting

<tsyesika> sandro: it's not so much that there is a cost to international dialing it's just that the cost is prohibitive

<hhalpin> This is simply a failure on W3C's part at this point, hopefully one we can address. I'll bring it up at our next meeting.

tantek: the chairs have talked abd we've agreed to switch to a flat FIFO format

<hhalpin> Not having free calling, particularly given the widespread use of VoIP, is ultimately IMHO discriminatory

tantek: if there are any objections let us know, we'll be happty to listen to questions/issues

<tsyesika> hhalpin: thanks

<hhalpin> biasing meetings towards those with the income to dial-in. If someone is not technical enough to figure out VoIP, it begs the question of what htey are doing in a technical standardization committee.

Arnaud: it does mean if you want to add somethign to the agenda, you must always add your things to the bottom of the list

tantek: if you have a speicifc action item that you want people to look at or are stuck on, you can add it to the agenda explicitly

<hhalpin> Thus, I fully support moving the meeting to Mumble if possible, and am happy to revisit this issue now that Ann (who previously had issues with this) is not in the WG.

<hhalpin> Many open-source projects use Mumble for telecons and it works well for them.

tantek: looks like there's a side conversation continuing
... i'm going to point out there's a free option for dialing in which I am using
... which is the google hangouts application
... it does allow free POTS phone calls to US phone numbers no matter where you are in the world

<cwebber2> tantek: I know tsyesika and rhiaro have been using that and it has been difficult for them

tantek: i've used this in manyu locations, so i don't actualy think there is a point about cost for the phone call
... there is a free solution to making phone calls
... and it's a lot easier than setting up a VOIP solution

Improvements in compatibility of IANA link relations registry with JSON-LD

tantek: while it's an interesting issue to discuss, i don't think it's something relevant or blocking AS2
... elf is this somethign that really needs to be discussed?

elf-pavlik: i wanted to share a quick update
... AS vocab defines properties like previous last next, thanks to this progress, you'll be able to reuse these more easily
... we can reuse these from well defined link relations instead of redefining them

tantek: if there are specific issues on AS use of vocab they should be filed as issues on github against each vocab item
... encouraging reuse tends to be good practice, but youcan capture this with specific issues and exampels on the spec

AS2 Hackathon

tantek: Now that we have the beginnings of a test suite, it would be great to get some Free and Open Source Software library implementations in major Web programming languages (Ruby, PHP, Python, JavaScript, Java, Go, Objective C). A weekend hackathon ahead of our next F2F would be great. Doodle poll here: http://doodle.com/poll/sht6vdmr73v2arfd

<cwebber2> wow nice job

<cwebber2> aaronpk: you're so on top of things!

<wilkie> I wanted to do that anyway!!

tantek: i believe the only action being requested here interest you, answer the doodle poll
... i will also point out there' sbeen an indiewebcamp hack day scheduled for the day after the F2F on Dec 3rd
... also hosted at Mozilla, so if you want to extend your stay to hack on AS2 or other socialweb technology for your personal website, you're welcome to join the indiewebcamp hack day

IndieWebCamp MIT Nov 7-8

<ben_thatmustbeme> There is an IWC at MIT on Nov 7/8th as well

<rhiaro_> https://indiewebcamp.com/2015/MIT

IndieWebCamp SF Dec 3

<tantek> https://indiewebcamp.com/2015/SF

tantek: participation is free, just show up. not just a WG event, it's open to anyone who wants to hack on their personal sites
... i believe the intent of the doodle poll is to make it open to anyone, not just WG members

ben_thatmustbeme: i wanted to mention there's an indiewebcamp at MIT on Nov 7/8, linked in the chat

tantek: looks like we have a pretty busy couple months coming up, good news

Social API

update and next steps

<rhiaro_> http://rhiaro.github.io/Social-APIs-Brainstorming/socialapi

rhiaro: as promised, i put togheter a document for a skeleton of what the social api could look like
... kind of the shape of the socail api. the pieces of how I see the API such that tey're interoperable but not dependent on each other
... your'e able to implement subsections but not necessarily all of them
... allows apps to work together rather than a single app the does everything
... it's obviousluy not impelmentable in its current form, and some sections have conflicting options, so i'm hoping the group can help work through this to resolve
... my plan is to work through and implement each part to refine it
... based on what i'm building and the other specs we've considered

<wilkie> great work

rhiaro: (activitypump, indieweb ones, and solid)

<cwebber2> rhiaro++

rhiaro: i might end up makign specific proposals based on what i'm building

<cwebber2> what wilkie said

rhiaro: i'm open to changing the structure , it's possible i've mised some stuff others think its important
... so i'd love for that to be fixed

<wilkie> this gives a great roadmap for implementations

rhiaro: the first section is reading, social data exposed on the web ,doesn't matter how it got there
... you find some, here's what to expect and how to get it

<wilkie> that are still flexible about Accept

rhiaro: the creating/updating/deleting shoudl be self explanatory
... discovery is the idea that you cn find content from a starting point, probably a user profile
... specifically that someone can publish multiple feeds of content, sorted to whatever criteria you'd like, and an a[plication like a reader needs a way to find all the content the user has published
... subscribing, specifically when your client is asking to be notified of updates, either to a single piece of content or a feed
... this is similar to mentions, which is when you're pushed a notification but didnt' necessraily ask for it
... subscribing and mentions are kind of mixed together in ActiivtyPump but are separate in indieweb protocols
... i found it useful to think of kthem separately
... the final section is profiles, auth is out of scope, identity is complicated and has a lot of baggage, but we basically need some document to describe the author of a document
... peopel can have multiple profiles, we don't need to constrain what goes into the profiles (orgs or bots are fine)

<ShaneHudson> Apologies I can't be on the call today, but just wanted to mention I'm up for the AS hackathon it is a good idea. Have put dates I can do on the doodle.

rhiaro: my instinct is to focus on this from the perspective of content delivery (social content)
... specifically with relationships between profiles, it's easy to get bogged down by categorizing friends
... but what really matters is what content is going to flow from user to users
... iv'e tried to capture this from a practical point of view without getting too concerned about identity

<cwebber2> aaronpk++

<ben_thatmustbeme> aaronpk++

tantek: i have adocument level question rather than a content question
... what would it take to turn this into an editors draft

rhiaro: i was going to end the doc with a question, if this is an acceptable way forwrads, i could add this to the w3c github and respec it and call it an editor's draft and go from there
... it just has some gaps and things that need to be filled but is a starting point

<sandro> gaps are business-as-usual for editors drafts. :-)

tantek: certainly editor's drafts are expected fto have issues and gaps

<Zakim> elf-pavlik, you wanted to ask about groups

elf-pavlik: really amazing work amy. my question goes to profile and relationships
... i remember a few years ago, were missing groups
... do you see a place for groups in the social api?
... and the access control aspects

<Arnaud> anyone pushing back would have the burden of coming up with a counter proposal :)

<wilkie> I agree, groups are important

rhiaro: i completely forgot about that. off the top of my head, since you ca have collections of contents you could have collections of profiles which you could use for access control
... definitely something to think about

<wilkie> this is a FANTASTIC start though

cwebber2: great work. i think this doucment will be awesome as is, you mentioned something offline, interest in doing this for activitypump
... i wonder if other implementers will be interested as well
... where you mentioned restructuring the activtypump document in this form
... are others interested in this?

rhiaro: yeah the other thing i'm doing, i came up with this structure and I am rewriting the activitypump API in this structure, leaving the content but just changing the structure
... iw ill be doing the same for solid
... and then the different indieweb specs are arleady in these pieces so they just need to line up in this order
... there are probably some parts that look the same when you untangle them, and then they can be put in the social API

<cwebber2> great rhiaro, awesome work!

rhiaro: i'm going to do it anyway but if anyone wants to help that's good too

<ben_thatmustbeme> rhiaro++

<kevinmarks> rhiaro++

hhalpin: it's a good beginning, i had two scoping questions
... i think we'll need some sort of minimal profile social graph annotation
... but i don't want this document to try to define that
... the most variance is in the subscription protocols
... it seems like the other thing is missing is there are two different design patterns in discovery
... one is looking at link headers, whcih some developers don't know about
... many people use acitivtypump without looking at link headers

<wilkie> that's so true and so baffling

hhalpin: most social networks don't use link headers
... maybe we should defined some default URL endpoints in the discovery
... look at some of the work done around webfinger and host-meta

<cwebber2> and also note

hhalpin: i'm happy to share those over email

<kevinmarks> webfinger is mostly dead isn't it?

<melvster> webfinger--

<cwebber2> that we have a lot freedom in ActivityPump to adjust the way discovery is done

rhiaro: i agree about not defining social relationship at the api level

<hhalpin> I'm going to note that vocabularies are a source of endless bike-shedding, let's not try to define in an API

<cwebber2> the stuff in there right now was rushed in for the paris F2F

tantek: i'm going to interject based on harry's comment

<hhalpin> Discovery is currently only done with Link Headers, but some folks don't use those or know about those.

tantek: regarding the suggestion to look at webfinger/host-meta, is anyone here actually implementing those in their social web technologies or solutions?
... i'm askign implementers that are on the call

<wilkie> negotiating has always been weird where you look for link headers, look for <link>, look for html hints somewhere else... link headers are priority though

<kevinmarks> gogole dropped webfinger support https://client.webfinger.net/lookup?resource=kevinmarks%40gmail.com

<tsyesika> yes, mediagoblin uses it

hhalpin: most of the large implementers who are not on the call tend to use webfinger
... most platforms don't use link headers, thye just use URL patterns that are documented

<tsyesika> I have no mic, but mediagoblin dos

<tsyesika> *does

<hhalpin> It might be useful to look at URL patterns default and that most major sites (for example, anyone that supports OpenID) uses WebFinger.

tantek: the reason i'm bringin this up is we've had no active participiation from implementers using these techniques, so i'm not in favor of trying to guess their needs and desires

<ben_thatmustbeme> we had agreed on follow your nose for endpoints a F2F Cambridge

<hhalpin> So we should at least look at this.

tantek: iwould prefer fewer things that are based on actual participants instead
... there are communities here, indieweb and solid, who are actively using link headers and relations and actively not using webfingers and host-meta

<melvster> ben_thatmustbeme++

<cwebber2> o/

<elf-pavlik> follow your nose by including links in payload https://lists.w3.org/Archives/Public/public-socialweb/2015Oct/0057.html

tantek: the current deployment and active work is to not use webfinger

<hhalpin> Again, the real focus for most people are using URL patterns

cwebber2: both mediagoblin and pump.io currently use webfinger
... and diaspora

<hhalpin> Anyways, people should look at it: http://tools.ietf.org/html/rfc7033

cwebber2: i'm not saying i think it's the best option, but there is active federation using it

<wilkie> yep, anything that stemmed from ostatus will be using it

<wilkie> my implementations also do

<kevinmarks> yahoo has also dropped webfinger

tantek: as an implementer, what's your opinion, si that worth mentioning in the social API?

<hhalpin> https://tools.ietf.org/html/rfc6415 - Host-meta

<kevinmarks> so how are you looking up things?

tantek: i'm seeing side comments in IRC, and i would request those queue up to make youre points
... is webfinger a backcompat thing?

cwebber2: i don't have the biggest strongest opinion on this, but it's the way things are going
... i know evan has expressed previous inteterest in webfinger
... but the activitypump we submitted for the f2f had a rough thing where we pulled jsonld out of the page, but i dont tihnk that's the best way forward
... it will at least need to be supported for backcompat, but i can't speak for evan

<tsyesika> cwebber++

tantek: thanks i appreciate that

<hhalpin> We saw in the wild *mild* uptake of WebFinger and Host-meta, I agree it may not be the best way forward, but *only* Link Headers ignores the facts that many developers do not know what Link headers are and that design pattern is not employed by major social networks.

<melvster> FYI: webfinger JSON is not compatible with the JSON proposed in this group

<cwebber2> that's true

<cwebber2> we did say that

ben_thatmustbeme: we did talk about this at f2f in cambridge and we agreed and pretty sure we had a resolution we would prefer a follow-your-nose method than a random URL

tantek: that's true
... that was this past march

<cwebber2> and that's why the paris f2f one had an alternate method

<cwebber2> that was FYN'ish

<cwebber2> though not a permanent one

tantek: we did resolve the group would use follow-your-nose method, to avoid well-known path methods
... so i suppose that leaves us with, if there is new information since the meeting we can reopen the issue

<cwebber2> tantek: anwyay, I think tsyesika and I are flexible on this, I think we'd be happy to work with the group

<cwebber2> tantek: we might want in activitypump to provide a backwards compatible note

kevinmarks: webfinger has been largely abandoned as far as i can tell
... the model that everything starts from eamil address was flaky to begin with
... google and yahoo both dropped it already

<melvster> kevinmarks++

tantek: do you have a citation for that?

kevinmarks: i used the webfinger.net client to look up my gmail and yahoo addresses and neither of them worked

tantek: so there's no official announcement, but based on the tests you're seeing the support gone

<wilkie> I'm not sure why google or yahoo would want to use webfinger haha

hhalpin: i'm not saying that webfinger or host-meta is the best approach, but I do think they were added to the OpenID connect spec

<kevinmarks> they're well-known urls

hhalpin: that being said, tho we should encourage HTTP link headers, lots of implementers don't know what link headers are
... some of the main questions implementers had was where shoudl i put my endpoints, and how do i find others' endpoints

<kevinmarks> we should support <a> as well as <link>

hhalpin: typically there is some documentation like twitter which shows the endpoints
... it may be useful to say if you're adding this to yoursite, here are some default patterns you can follow
... that follows more clearly what implementers are used to

<kevinmarks> wordpress has link headers

<kevinmarks> so ~25% of the web

tantek: that's an interesting assertion, but i'm not sure without some evidence of where those endpoints are we can come to a conclusion

<hhalpin> So, does Twitter, Facebook, or anyone else use Link Headers?

<hhalpin> I think Evan began this research a while back.

<hhalpin> So we already have lots of data.

<kevinmarks> silo.pub has instructions for adding link headers to other silos

tantek: counterpoint i'll provide is there are many more sites and URLs that have link headers and link rel discovery of rss/atom feeds
... iw ould assert the number of sites that support that greatly outnumber all proprietary social netweork APIs combined

<hhalpin> I think Link Headers are not a bad way to go and should be specified, but having some "optional" advised default end-points will help deployment.

tantek: so there are many publishesr and consumers that use feed discovery from home pages

<Zakim> elf-pavlik, you wanted to mention including links in body of response

tantek: i'm presenting that to counter that developres don't know what to do with link relations

<hhalpin> I think RSS/Atom feeds are slowly on their way out, sadly :(

<elf-pavlik> http://ruben.verborgh.org/blog/2015/10/06/turtles-all-the-way-down/

<wilkie> just do what everybody else does. do link headers, and fall back to link tags, etc.

<kevinmarks> opensocial/as1 defined api paths relative to an endpoint

<tantek> they (RSS, Atom) still greatly outnumber proprietary APIs

<hhalpin> I'm just noticing that the main way discovery is usually done is by going for a URL

<tantek> hhalpin, not for feeds

elf-pavlik: it seems like activitystreams and others put links in the body of responses

<tantek> that's still done by follow-your-nose via link relations

<hhalpin> So losing that pattern and saying "look at link headers" seems rather odd if we want deployment.

elf-pavlik: html links in the indieweb community also put links in the body
... it's not just link headers, we can use the payload in the body, so there are other options

<hhalpin> For internationalization and adoption, I agree Link headers are a good thing, but I think 99% of people will be expecting URL endpoints that are defined.

sandro: can we do quick point of order of where we are on the agenda?

<cwebber2> I'm happy to dequeue

<Zakim> rhiaro_, you wanted to make proposal about API

<rhiaro_> PROPOSAL: accept this basic structure of a Social API document and continue development on w3c-social github. Have an implementable draft ready by the f2f.

rhiaro: i wanted to end this with a proposal

<cwebber2> I'll say it on IRC instead

<elf-pavlik> +1

tantek: sounds like you're proposing it as an editor's draft

rhiaro: if that's what it sounds like sure, i'm not sure what the full process is

tantek: i'm going to reword your proosal slightly

<kevinmarks> hhalpin: Iink headers just point to the defined api endpoints. I don't see how link headers are bad

<tantek> PROPOSAL: accept this basic structure of a Social API document as an editor's draft for the WG and continue development on w3c-social github.

<elf-pavlik> +1

<cwebber2> hhalpin: I agree with you on the general "what developers can easily pick up and go with with the tooling they have", but I think that looking at a spec and hearing "oh I can get it from here"... most devs have the tools in a django/rails/node blah blah type environment to where webfinger and link relations and etc are about equal complexity

<sandro> +1

<ben_thatmustbeme> +1

<tantek> +1

<cwebber2> +1

<rhiaro_> +1

tantek: the progress of the draft is up to you, which is why i dropped "implementable"

+1

<hhalpin> +1

<cwebber2> it also seems like an easy one for the group to not disagree too much over :)

tantek: i see a bunch of +1s

<kevinmarks> +1

<wilkie> +1

<cwebber2> so I'm happy to say "webfinger is backwards compatibility"

<cwebber2> and move on

sandro: might be nice to aim for getting a first public WD by the f2f

<tantek> RESOLVED: accept this basic structure of a Social API document as an editor's draft for the WG and continue development on w3c-social github.

tantek: i'm not seeing any objections at al, so i'll declare it as resolved

rhiaro_++

<elf-pavlik> rhiaro++

<cwebber2> rhiaro++

<sandro> rhiaro++

rhiaro: i don't know what state it has to be in for it to be a working draft but as long as someone can clear that up for me that's okay

sandro: there's some mechanical stuff harry and i can help with

<hhalpin> Note that FPWD and Editor's drafts don't need WG consensus

sandro: from a consensus point of view it's either agreed on or noted that it's not agreed on

rhiaro: okay that sounds doable

<hhalpin> Otherwise, there would likely never be a published FPWD :)

tantek: in general working draft does not require all the contents to have consensus, that's how we broaden the discussion

TPAC

<hhalpin> There was a request from Annotations for Social members at TPAC to attend as well

tantek: "Those attending TPAC will hold a Social Web breakout session on the plenary day. Please suggest agenda topics."

rhiaro: on wednesday of next week during tpac, there's breakout sessions, and tantek Arnaud and me will be there, there will be a social web session 1 hr
... if anyone wants to bring something up for the session add it to the wiki pag

hhalpin: there was also a request, the annotations WG is meeting and they might have some dependencies on this group
... .they invited this group to their meeting

TOPIC AS 2 modularity

tantek: last week there was a straw poll of whether we should consider AS to be a requirement
... there was some active resistance and opposition
... the chairs discussed what is a good way forward
... i believe sandro has a good summary to present

sandro: HTML clearly uses and carries and works with Javascript and CSS, but it does not have any hard dependency on them
... it's possible to use different stylesheets, but everyone in the industry knows everyone uses javascript/css
... i was hoping we could in theory have the API be separate from the social media syntax
... .that could be a good design pattern, even if we all know that what we do most of the time is use AS2
... chris said it seems like a failure if we don't tie the two together. i'm saying it doesn't have to be a failure, see HTML

<cwebber2> http://www.w3.org/TR/CSS1/

cwebber2: HTML does not link to CSS, but CSS does link to HTML everywhere
... so it's true that HTML is a foundation on which CSS sits, but CSS is dependent on HTML

<csarven> SVG?

cwebber2: so i'm not totally sure i buy this analogy

tantek: i'll quickly give a counterpoint. in CSS2 it was explicitly made more modular than CSS1, CSS2 made it clear that it works on any document language, not just HTML
... acknowledged that tying CSS1 to HTML was a mistake
... we can certainly learn from that
... csarven mentioned SVG. SVG was able to reuse aspects of CSS without CSS having to change
... that was a good design mechanism
... .the other explicit point i wanted to add to sandro's analogy
... in scripting, there were multiple alternatives you could use in HTML. all those alternatives were devleoped outside w3c

<cwebber2> tantek: ok, point taken re: css 2

tantek: our modularity is not just restricted to w3c's work, but can and should extend to allowing development outside our work
... the other example of styling languages. there were multiple alternatives pursued inside w3c
... when we got to XML, it could be styled with CSS or XMLFO

<hhalpin> Although XSL-FO seems not to have worked out...

tantek: my experience is having those two ended up benefiting both

<hhalpin> That being said, I've used XSL-FO for styling XML produced by wikis into PDFs for a textbook, it's quite fun in a very XML-centric way.

tantek: eventually yes we have a dominant styling and scripting language, but that took years to happen, and the existence of alternatives benefitted both
... the modular approach will benefit all our technologies the most
... so to those who were -1 to requiring AS2 would want to present an alternative

<ben_thatmustbeme> another reason to keep Social API and Federation API seperate

tantek: clearly there are folks who are unhappy with AS2
... one way to continue AS2 is for those who were -1 to give a counter proposal
... if you have a way to define what you would like constructively instead then we can design the protocols so they are moduled

<Zakim> elf-pavlik, you wanted to discuss AS2.0 trying to address API concerns

elf-pavlik: i already mentioned that AS is trying to address API concerns, paging and media types, i plan to create an issue listing all the API concerns that AS has to address
... so we can focus ont he data

<ben_thatmustbeme> elf-pavlik++

tantek: that sounds great

hhalpin: i think the concern is if we don't have a SHOULD for some json format, multiple sides will use the aPI and won't interoperate

<kevinmarks> why does harry think microformats are anti-json?

hhalpin: we'l end up with lack of interoperability. rather than consider this a format war, we should try to accept one JSON based format

<cwebber2> kevinmarks: not that it's anti-json but that it won't be the same json maybe?

<cwebber2> clearly aaronpk is working on a json format and that's great

<hhalpin> It's not, that's why I'm confused re resistance to JSON formats since mf2

tantek: i'm going to reiterate what sandro said. HTML did not have a SHOULD MUST or MAY for javascript or CSS, and CSS says "if you're using HTML here's what to do"
... not only should we not say MUST, we should not say SHOULD either

<kevinmarks> there isn't resistance to JSON

<ben_thatmustbeme> hhalpin: i am going to try to come up with a standard JSON format that AS2 and MF2's JSON can both translate to

<hhalpin> Modularity that destroys inteoperability is a bad idea.

hhalpin: modularity that destroys interoperability is bad and i'll go on record saying that

<ben_thatmustbeme> hhalpin: which btw, was inspired by your talk

tantek: the example given counters that, so unless we have actual harm demnonstrated we have one positive example and no negative examples

<tantek> action-35

<trackbot> action-35 -- Tantek Çelik to Come up with a simple proposal for implicit typing based on property names -- due 2015-02-10 -- PENDINGREVIEW

<trackbot> http://www.w3.org/Social/track/actions/35

<hhalpin> Indeed the world shows that Javascript+HTML5 is a dominant paradigm

actions and issues

<cwebber2> ben_thatmustbeme: you probably want to work with aaronpk on that

<hhalpin> Javascript+CSS+HTML5

<hhalpin> If there's a world where CSS is used on something other than HTML, I'd like to know

<wilkie> tbf, it would technically be possible to make a social api implementation that produces no data if all possible outputs are SHOULD haha

<hhalpin> Otherwise, it's pretty clear the example re modularity doesn't make sense

<cwebber2> wilkie: haha

<rhiaro_> wilkie: haha, social ghosts

<cwebber2> ben_thatmustbeme: aaronpk is already exploring that, you can probably maximize efforts by working together

<wilkie> cwebber2: I like the art/philosophy of that kind of system.

Arnaud: normaly this is the way for someone to signal you want this to be looked at by the WG

<kevinmarks> JSON-LD islands in <script> are the weird thing here

<cwebber2> wilkie: no data is good data

<tantek> PROPOSE close action 35 as completed with the Post Type Discovery Editor's Draft

<elf-pavlik> actions don't need formal resolutions

<cwebber2> no data complies with all specs

<hhalpin> Precisely wilkie. If there is folks that disagree with JSON, then I suspect their systems will simply not be made interoperable with.

<wilkie> cwebber2: you're not wrong if you don't try

<cwebber2> :)

<ben_thatmustbeme> +1

RESOLVED close action 35

<cwebber2> thanks for chairing tantek !

<kevinmarks> harry, you're strawmanning

<elf-pavlik> thanks all!

<wilkie> thanks all

<hhalpin> No, I'm not straw-manning.

trackbot: end meeting

<cwebber2> and thanks for excellent scribing aaronpk

hhalpin: http://www.sitepoint.com/svg-styling-with-css/

<hhalpin> I think people should accept JSON and MAY accept other things

Summary of Action Items

[End of minutes]

Socialwg/2015-10-20-minutes