Re: objections to webmention

Those are all serializations of data though. The WG already has as2 for
that.  The data fetched from the page could be in any of those formats.
Webmention is a different layer.  The nicest part of webmention is that it
is totally agnostic to what serialization you want to use.  Loading data in
to the webmention is pretty clearly out of the use case for the spec.
Sure, you COULD. But it's just as silly as saying you could load all data
in to headers in HTTP.  And then arguing that HTTP needs to specify how to
translate that genetically to as2.
On Jun 7, 2016 8:45 AM, "Melvin Carvalho" <melvincarvalho@gmail.com> wrote:

>
>
> On 7 June 2016 at 13:47, Ben <ben@thatmustbe.me> wrote:
>
>> So I'm confused by this.
>>
>> > What I want from webmention is for it to be interoperable with existing
>> work.  That means the spec should explain how to do this to implementors.
>>
>> It's a spec.  To be interoperable, implement the spec.  Also, the
>> existing work is existing implementations of webmention.  Other existing
>> but similar work in this area are specs like pingback, etc, for which
>> replacing those with the new spec is fairly straight forward. What work are
>> you trying to make it interoperable with?
>>
> Im not so worried about pingback.
>
> Generalized messaging over the web is an area the w3c has innovated.
> There are a number of projects that have done work to be interoperable with
> w3c recommendations, particularly in JSON (LD).  Now JSON-LD is also
> interoperable in a deterministic way with XML, with turtle, with a number
> or other serializations (already W3C RECs).  That means if you support any
> one of these you can translate between the others for free.  So there's
> dozens of systems and millions of sites that follow this work.  Facebook
> publishes in this style.  Google publishes and consumes in this style and
> many others.  Solid has done a lot of work to start to support JSON which
> we were lead to believe would be the common ground for messaging in this
> group.  The list of implementations in this eco system is growing.
>
>
>> > Either fully specify how to pass extensible messages around using form
>> encoded variables, which hasnt been done, but could be in a WG.  Or provide
>> a complete mapping with at least an example of how to do this, in, say,
>> JSON.
>>
>> This does not make sense for centralized extendability.  The idea is in
>> order to be extended it needs some level of rigor and a normative
>> reference.  Do you just want a line that says something along the lines of
>> "extensions can be experimented with but in order to be official extensions
>> they have to go through w3c process"?  That seems rather pointless to state
>> to me.
>> On Jun 7, 2016 6:32 AM, "Melvin Carvalho" <melvincarvalho@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 7 June 2016 at 05:48, Sandro Hawke <sandro@w3.org> wrote:
>>>
>>>>
>>>>
>>>> On June 6, 2016 9:17:09 AM PDT, Melvin Carvalho <
>>>> melvincarvalho@gmail.com> wrote:
>>>> >On 6 June 2016 at 04:41, Sandro Hawke <sandro@w3.org> wrote:
>>>> >
>>>> >>
>>>> >>
>>>> >> On June 5, 2016 2:14:49 PM PDT, Melvin Carvalho
>>>> ><melvincarvalho@gmail.com>
>>>> >> wrote:
>>>> >> >On 5 June 2016 at 22:20, Robert Sanderson <azaroth42@gmail.com>
>>>> >wrote:
>>>> >> >
>>>> >> >>
>>>> >> >> While I agree with Melvin's design aesthetics, I acknowledge
>>>> >that's
>>>> >> >what
>>>> >> >> they are.  There's no _functional_ problem with the current spec,
>>>> >and
>>>> >> >while
>>>> >> >> JSON-LD and URIs seem like a good practice, there's nothing
>>>> >written
>>>> >> >in
>>>> >> >> stone that says Thou Must Use URIs.
>>>> >> >>
>>>> >> >> I disagree however that it's a general purpose messaging
>>>> >framework.
>>>> >> >It's
>>>> >> >> explicitly (per the one sentence introduction):
>>>> >> >>   "[...] a Webmention is a notification that one URL links to
>>>> >> >another."
>>>> >> >>
>>>> >> >>
>>>> >> >> Basing any understanding of webmention on the non-normative
>>>> >> >extensions
>>>> >> >> referenced seems like a trap to be avoided.  I (personally) would
>>>> >> >simply
>>>> >> >> remove Appendix B and focus on the actual value of the main
>>>> >> >specification.
>>>> >> >> Extensibility without namespaces at web scale is just impossible,
>>>> >and
>>>> >> >may
>>>> >> >> be leading to some of the confusion and design questions.
>>>> >> >>
>>>> >> >
>>>> >> >Well put!
>>>> >> >
>>>> >> >So is webmention extensible, or is it not extensible.  I think this
>>>> >> >could
>>>> >> >be clearer.
>>>> >> >
>>>> >>
>>>> >> We need to distinguish between centralized extensibility like in
>>>> >html5,
>>>> >> css, uri schemes, schema.org, http headers, etc, and decentralized
>>>> >> extensibility, as in RDF or link headers.
>>>> >>
>>>> >> Webmention has centralized extensibility.   Activity streams (by
>>>> >using
>>>> >> json-ld) has decentralized extensibility.
>>>> >>
>>>> >> Personally, I feel like decentralized extensibility is a moral and
>>>> >> psychological issue, but I'm well aware that the case for
>>>> >decentralized
>>>> >> extensibility is weak.    The vision is of a wonderfully free and
>>>> >open yet
>>>> >> interoperable ecosystem, but in practice that doesn't seem to happen.
>>>> >By
>>>> >> far the greatest adoption of RDF happened when it was coupled with
>>>> >> schema.org, with only centralized extensibility.
>>>> >>
>>>> >> Given that, I think webmention is fine having only centralized
>>>> >> extensibility.
>>>> >>
>>>> >
>>>> >Slightly conflicting replies to the question.  Can I take away that
>>>> >webmention is indeed designed to be extensible, through some yet to be
>>>> >described, centralized means?
>>>> >
>>>>
>>>> Yes.   The spec has a section on extensions:
>>>>
>>>> https://www.w3.org/TR/webmention/#extensions
>>>>
>>>> If some lack of clarity or specificity in that section is causing you a
>>>> problem, please feel free to raise an issue on github.   For best results
>>>> tell a story about what you're trying to do with webmention and how the
>>>> current state of the spec causes you difficulty in doing that.
>>>>
>>>> Hypothetical arguments and appeals to authority are unlikely to have a
>>>> positive effect.
>>>>
>>>
>>> OK thanks, I've made the case against around centralized approach on
>>> another thread.  Not that I think centralization is evil, but that the
>>> opinions stated I felt were inaccurate.
>>>
>>> I dont see what is hypothetical about (re)using standards to grow the
>>> network effect?  You have not registered this point and I keep repeating
>>> it. We have good stats on JSON LD being used in millions of sites, ditto
>>> other types of linked data, and being liked by large companies such as
>>> Google.
>>>
>>>
>>>> >At this point, Im not attempting to debate the pros and cons of
>>>> >centralization vs decentralization in the social web, more initially to
>>>> >clarify the nature of the work.
>>>> >
>>>> >Im also going to suggest that the general case of this problem has
>>>> >already
>>>> >been solved by existing W3C RECs -- that might be a more contentious
>>>> >point,
>>>> >so I would be happy to hear if people think that's not the case.
>>>>
>>>> I covered that in a different email yesterday.   In any case, it's all
>>>> just background information.
>>>>
>>>> The key point may be that the working group decided in December to
>>>> proceed on multiple tracks.   That means only friendly amendments are
>>>> really appropriate.   You seem to want something quite different from
>>>> webmention, so it seems to me that means you should work on that thing,
>>>> e.g. activitypub (maybe now activitysub) or solid inbox or something.
>>>>
>>>> BTW the working group will be discussing webmention issues tomorrow at
>>>> the f2f,  and hopefully close all the open ones.
>>>>
>>>
>>> What I want from webmention is for it to be interoperable with existing
>>> work.  That means the spec should explain how to do this to implementors.
>>>
>>> Either fully specify how to pass extensible messages around using form
>>> encoded variables, which hasnt been done, but could be in a WG.  Or provide
>>> a complete mapping with at least an example of how to do this, in, say,
>>> JSON.
>>>
>>>>
>>>>
>>>>     - Sandro
>>>>
>>>> >>
>>>> >>
>>>> >>      - Sandro
>>>> >>
>>>> >>
>>>> >> >
>>>> >> >>
>>>> >> >> Rob
>>>> >> >>
>>>> >> >>
>>>> >>
>>>> >>
>>>>
>>>>
>>>
>