Re: objections to webmention

On June 7, 2016 7:09:27 AM PDT, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>On 7 June 2016 at 15:17, Sandro Hawke <sandro@w3.org> wrote:
>
>>
>>
>> On June 7, 2016 6:03:11 AM PDT, Ben <ben@thatmustbe.me> wrote:
>> >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.
>>
>> Exactly.   I was just going to use the headers analogy.
>>
>> Melvin, are very unhappy that all the http and smtp headers are not
>using
>> json-ld?
>>
>> Webmention is basically an http header that's sent preemptively,
>before
>> being asked for.
>>
>> Webmention is totally interoperable with everything, because the real
>> message content is indicated in the mention's source field and is an
>> arbitrary Web Resource.
>>
>> Asking for the "mention" itself to be interoperable with other stuff
>makes
>> no sense because there's no other stuff out there trying to do this.
>> (Well, maybe something about trackback, etc, but that's not the
>argument
>> you're making.)
>>
>> I keep making this point and you keep showing no sign of
>understanding
>> it.  Hopefully with Ben and I both making it more and more concisely,
>it'll
>> make sense now.
>>
>
>You are making an analogy between webmention and link headers.  I did
>acknowledge it.  More than once.  I man an analogy to HTTP GET.  I also
>made the analogy to the pub sub protocol of Solid.
>
>But we have established on this thread that webmention is an extensible
>messaging system.  It can be extended in all sorts of ways.  My
>experience
>is that this is likely.  We implemented semantic pingback back in the
>day,
>which is almost identical to webmention and indeed inspired its
>creation.
>Pretty soon we were passing around a comment along with the mention and
>so
>on.  I know you're going to say 'slippery slope argument' now :)
>
>But well im just saying if it's going to be a generic messaging system,
>that's fine, just specify it in a way that other systems know what it
>means
>in their language, and how to translate from one to the other.  Then
>everyone can use the same set of techniques.
>
>

My understanding is that argument has been heard, understood, and rejected by the working group.

If you want, I suppose we can go through it one more time today, but I don't have any reason to think the outcome will be different.    As you acknowledged, sometimes a general solution is overkill.  In the judgement of the people working on webmention, this is one of those times.   Why should they ignore their judgement and follow yours instead?

As I've said repeatedly and you also acknowledged, arguments from authority are not helpful to this group.   What's helpful is stories about real problems you face in trying to build some software while following the spec.

    - Sandro




>>
>>     - Sandro
>>
>> >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
>> >>>>> >> >>
>> >>>>> >> >>
>> >>>>> >>
>> >>>>> >>
>> >>>>>
>> >>>>>
>> >>>>
>> >>
>>
>>

Received on Tuesday, 7 June 2016 14:56:46 UTC