Re: Getting the group back on track

On 7 October 2015 at 01:06, Christopher Allan Webber <cwebber@dustycloud.org
> wrote:

> Hello all,
>
> So I initially wrote a different version of this email, but I thought
> today's call was lively enough that it deserved a rewrite.  So here
> goes!
>
> I'm glad to hear that there's a general concern in the group that we
> really need to get moving for real on the client to server / server to
> server APIs.  I was also happy to hear that in general people seem eager
> to get ActivityStreams to move forward.  Great news!  Now, can we do it?
> Can we fulfill the missions of this group?
>
> I think we can.  ActivityStreams 2.0 is already looking quite polished.
> Today we got some good clarity on what an ActivityStreams test suite
> would look like, and I can help on this.  But the deliverables of social
> api and federation api seem stuck in a rut.  At minimum, we need to
> agree on a format and move forward with it.
>
> Since it's already a deliverable, the mandatory format might as well be
> ActivityStreams + JSON.  It's okay to say in the specification that
> other formats are optional, and here's how to handle them, but
> ActivityStreams should be mandatory.  As Evan said on the call today, it
> would "look strange" to not have that be part of the official APIs the
> group puts forward.  But appearing non-strange is just one reason: the
> goal of this group should be putting forward a standard that the real
> world will probably use.  The real world is currently setting up
> endpoints that shoot JSON back and forth at each other.  Well, we've got
> a nice JSON supporting format, we should take that, declare that as a
> basis, and start defining how to shoot that across some endpoints.
>

-0.5

I dont think taking yet another JSON serialization to REC is a good idea,
when we already have a JSON REC (JSON LD) which is to all intents and
purposes identical.  I am wondering if there will be some formal objection
down the line.

I suspect you'll lose a big chunk the growling list of JSON LD implementors
and tooling in this effort, so I'll ask who's going to use it, and who's
going to implement the test suite?  Is there going to be the kind of
implementation interest there that you'd just want to throw away the
existing developer base?

And what do you gain?

I dont intend to prioritize implementing this, but could be persuaded if
some tooling arrives, but dont really see it happening in the short term,
we will see.

IMHO.  I cant fathom why you'd want a new mime type, other than NIH.
Decisions such at this slows the group down,


>
> By the way, it's my observation (and actually not at all just my
> observation, several people external to the group have raised this to
> me, even while I was traveling to FSF 30th just this last weekend) that
> one of the main causes of this group getting so "stuck in a rut" is that
> this group is caught in the crossfire that has been going on for 15
> years: Microformats vs Linked Data.  I have massive respect for people
> on both sides, and I'd love to see this group serve some purpose of
> seeing these sides come together, but more than anything I believe the
> opposite has happened: again and again we get caught into age-old
> arguments between these camps.
>
> The Microformats vs Linked Data war has been going on for 15 years.  If
> it hasn't been solved outside of this group in all this time, there's no
> way it can be reconciled inside this group.  Take it outside!
>

I dont think there's a war.  I think is a small vocal minority of the
microformats community have aggressively stated their world view, and are
less willing to compromise, making it look like a "war".  I dont see it as
such.  I see resistance on reusing generally agreed structures such as
awww, namespaces, vocabs and much of what the w3c has done in the last 10
years.  That slows us down.  There are also members of the microformats
community that are open to such ideas.  I think "known" which seems to be
the biggest part of the mf2 community have been very supportive.


>
> I have more to say on all the above subjects, but in the interest of
> keeping this email short, here's a summary: we already have a nice and
> dandy serialization format that fits the toolchains of most of the web
> frameworks out there.  We've spent a lot of time getting it to a state
> that the group seems reasonably happy with.  We should take advantage of
> that and move forward on recommending APIs that people can use.
>
> So, how about it?
>  - Chris
>
>