Re: objections to webmention

On 11 June 2016 at 17:23, Sandro Hawke <sandro@w3.org> wrote:

>
>
> Replying only because you raise some process points.   I continue to
> strongly encourage you, if you want to be helpful toward the group's
> mission, to either work on parts of the stack where you agree with the
> architecture (eg activity pub or solid), or, if you want to help with
> webmention, to tell true personal stories of difficulties you had using it.
>
> On June 11, 2016 1:29:59 AM PDT, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
> >On 8 June 2016 at 16:50, Sandro Hawke <sandro@w3.org> wrote:
> >
> >>
> >>
> >> On June 8, 2016 4:53:53 AM PDT, Melvin Carvalho
> ><melvincarvalho@gmail.com>
> >> wrote:
> >> >On 8 June 2016 at 13:12, Ben <ben@thatmustbe.me> wrote:
> >> >
> >> >> > My recommendation at this point, is for this work to be a Note,
> >and
> >> >> leave the door open for further standardization.
> >> >>
> >> >> Isn't that effectively saying you want it resolved outside of the
> >> >working
> >> >> group?
> >> >>
> >> >No no!
> >> >
> >> >I think it's good work, in general.  Im happy that it was done.
> >Ideal
> >> >way
> >> >is to resolve issues here.  It's slightly awkward with tantek having
> >> >boycotted the mailing list, but I dont give up hope!
> >> >
> >>
> >> The preferred place to discuss issues on a specific spec is github.
> > I
> >> opened an issue for you for this, to help encourage that, but then
> >> eventually closed it because you weren't using it.
> >>
> >
> >The github process is rather hit and miss.
>
> W3C process holds groups accountable for how they handle issues, but lets
> it them select among several fora for doing so.  This group has selected
> github, so if you want your comments to be part of the accountability
> process, you should make them there.
>
>   It works well in some
> >groups
> >and even here with james snell, however some of us have made an effort
> >to
> >use other repos and the feeling is that the process is broken.  In
> >particular with admin rights being granted to people with a clear
> >conflict
> >of interest who close down and lock issues before they have been fully
> >discussed.
>
> I believe you're referring to a specific incident on about November 30,
> 2015, which led the WG to clarify its github issue process.   My
> understanding is that incident arose from the editor simply being
> unfamiliar with W3C process and instead using a different (more
> dictatorial) process familiar to him.
>
>
> >
> >Your own words on the github process described in the wiki : "The rules
> >are
> >TERRIBLY explained and justified"
> >
>
> Sounds like me being apologetic and also angry about the above incident.
>   The helpful thing to do in that case is ask for clarification where the
> intent is unclear, and perhaps offer editorial suggestions.    I was
> rewriting the document until I got the sense no one actually cared and
> stopped spending my time on it.
>
> >Some in the WG have made an effort on github but found the process not
> >to
> >be a productive use of time.  Additionally, for structural problems in
> >a
> >specification, I might suggest that mailing list which has a wide
> >readership can be helpful.
>
> I personally have no evidence anyone but you and I are reading this, or
> that this is a productive use of time.    There probably are a few other
> people still reading this, but they could just as easily read it via github
> (which will happily email thread contributions to people.)   In fact, this
> email list is limited to WG members, while the github issues are not, so in
> sense github may lead to wider review.
>

Is it not a requirement of WG members to be subscribed to this list?

"Each group *must* have an archived mailing list for formal group
communication (e.g., for meeting announcements and minutes, documentation
of decisions, and Formal Objections
<https://www.w3.org/2015/Process-20150901/#FormalObjection> to decisions).
It is the responsibility of the Chair and Team Contact to ensure that new
participants are subscribed to all relevant mailing lists."

http://www.w3.org/Consortium/Process/


>
>
> > , I've been contacted out of band by a
> >number of people in the space, supporting the points I make.
> >
>
> Interesting claim.    Perhaps you should move this to github where they
> can add to the support counters for your comments, if they don't want to go
> so far as to actually comment.
>
> But I'd strongly encourage them, as I do you, to tell true stories of how
> they tried to use webmention and ran into difficulties.    If they don't
> have such stories, I'm sorry to say the foundation for their encouragement
> sounds more emotional than factual.
>
> >This thread has been valuable in that it has established clearly that
> >webmention is an extensible messaging system.
>
> I'm sorry, Melvin, but that's a ridiculous claim.  The extensibility was
> always clear from the spec, which has a section on extensibility, and the
> fact that it's a sort of messaging system is obvious since that's what all
> networking protocols are.
>
> You tried to argue that it was a GENERAL PURPOSE messaging system.   If it
> were then your argument that it should use a general purpose data format
> would have considerable weight.    But it is not a general purpose
> messaging system.  Quite the contrary.
>
>     - Sandro
>
>   As such it ought to at a
> >minimum be compatible with the social syntax this group is chartered to
> >create.
> >
> >
> >>
> >> >Just not seeing why it should be REC, rather than Note, at this
> >point.
> >> >
> >>
> >> Because it appears it will meet all the criteria for a Rec.
> >Otherwise
> >> it's like a 5th grade student being enrolled in the 2nd grade.    You
> >seem
> >> to think it really still belongs in 2nd grade but it's already met
> >the
> >> objective criteria for graduating 2nd and seems fairly likely to do
> >the
> >> rest soon.
> >>
> >> >What I'd like to see is webmention having a mapping to linked data,
> >> >interoperate with that, and the millions of sites that use it
> >> >(including
> >> >facebook and google), and also to have its form encoded version,
> >seems
> >> >to
> >> >be the best of all worlds.
> >> >
> >>
> >> Just because two systems use JSON-LD doesn't make them interoperable.
> >>
> >> Acting as if it does is the Semantic Web "handwaving" or "pixie dust"
> >that
> >> some folks find offensive.   It's what creates the "RDF allergy".
> >>
> >> There is adoption for ogp and schema.org in part because they're a
> >whole
> >> lot more constrained than just using RDF.  The other constraints are
> >> necessary to provide interop.
> >>
> >> If you can show a plausible way to provide them for webmention, then
> >I'll
> >> be intrigued.    I've thought about it a lot and don't think it's
> >possible.
> >>
> >>     - Sandro
> >>
> >> >
> >> >
> >> >> On Jun 8, 2016 6:59 AM, "Melvin Carvalho"
> ><melvincarvalho@gmail.com>
> >> >> wrote:
> >> >>
> >> >>>
> >> >>>
> >> >>> On 8 June 2016 at 11:28, Melvin Carvalho
> ><melvincarvalho@gmail.com>
> >> >>> wrote:
> >> >>>
> >> >>>>
> >> >>>>
> >> >>>> On 4 June 2016 at 02:02, Sandro Hawke <sandro@w3.org> wrote:
> >> >>>>
> >> >>>>> On 06/03/2016 07:15 AM, Melvin Carvalho wrote:
> >> >>>>>
> >> >>>>> I've attempted to communicate for the last year, on irc and in
> >> >aarons
> >> >>>>> github area, but its sometimes been not an optimal use of time.
> >> >So I'd
> >> >>>>> like to formulate my objections to webmention here, for further
> >> >review,
> >> >>>>> with hopefully some possible solutions.
> >> >>>>>
> >> >>>>>
> >> >>>>> Hi Melvin,
> >> >>>>>
> >> >>>>> You've caught me at an excellent time to write a detailed reply
> >--
> >> >I'm
> >> >>>>> on the plane to the F2F meeting.  This is just the right kind
> >of
> >> >work for
> >> >>>>> this situation.  Hopefully this reply will make everything more
> >> >clear.
> >> >>>>>
> >> >>>>> It looks to me like your objections here are based on your
> >design
> >> >>>>> sense, your general sense of what good designs look like,
> >rather
> >> >than on
> >> >>>>> specific concerns about use cases that can be addressed with
> >one
> >> >design
> >> >>>>> versus another.
> >> >>>>>
> >> >>>>> In the most recent previous discussion on this topic, at
> >> >>>>> https://github.com/aaronpk/webmention/issues/39, I repeatedly
> >> >asked
> >> >>>>> you to provide specific use cases, to explain how
> >developers/users
> >> >would be
> >> >>>>> affected by some change you're proposing.    I haven't seen an
> >> >answer.
> >> >>>>>
> >> >>>>> Perhaps you thought I was just doing that as way of dismissing
> >> >you, of
> >> >>>>> giving you busy work?    That's not the case.    I was doing it
> >> >because by
> >> >>>>> arguing from uses cases, a group has a reasonable chance of
> >> >reaching
> >> >>>>> consensus.  Arguing from design sense pretty much never leads
> >to
> >> >>>>> consensus.   It's a bit like the difference between science and
> >> >religion.
> >> >>>>> With the scientific method, disagreements can usually be
> >settled
> >> >by
> >> >>>>> replicating experiments and developing new ones.   Not so much
> >> >with
> >> >>>>> religion.
> >> >>>>>
> >> >>>>> So, again, I'll say if you want to persuade the group of
> >anything,
> >> >I
> >> >>>>> think you're going to have to lay out a use case.    I suggest
> >> >taking some
> >> >>>>> part of one of the agreed-upon users stories and show how the
> >CR
> >> >version of
> >> >>>>> Webmention doesn't work very well but some alternate version
> >> >you're
> >> >>>>> proposing does.
> >> >>>>>
> >> >>>>> Personally, I don't think you'll be able to do this.  I've been
> >> >>>>> thinking about this space, a lot, for years, and I don't see
> >the
> >> >issues
> >> >>>>> you're raising as the kind of issues that could lead to
> >material
> >> >use
> >> >>>>> cases.   But you're welcome to try.
> >> >>>>>
> >> >>>>> A key question is what you're trying to do here.    If you want
> >to
> >> >>>>> improve Webmention, that's probably the way to do it.   If you
> >> >just want to
> >> >>>>> be a pain to the WG, you could raise a formal objection.   (I'm
> >> >not going
> >> >>>>> to consider this "objection" a "formal objection" unless you
> >> >specifically
> >> >>>>> use that phrase.)  But unless you can be more clear in the way
> >I
> >> >suggest
> >> >>>>> above, I don't think that'll do anyone any good.   Normally a
> >> >Formal
> >> >>>>> Objection is used to make a Working Group spend some time
> >> >seriously
> >> >>>>> reconsidering some decision it made.   But I don't see a
> >decision
> >> >the WG
> >> >>>>> has made around Webmention that it might change during a
> >> >reconsideration,
> >> >>>>> unless some new information was presented.
> >> >>>>>
> >> >>>>
> >> >>>> Thanks for responding to my concerns.
> >> >>>>
> >> >>>> I was glad to learn that I am not the only person in the WG that
> >> >has
> >> >>>> reservations on this work.
> >> >>>>
> >> >>>> I dont feel the concerns have been addressed, other than the
> >hand
> >> >>>> waiving, "I dont find that compelling" argument, which can be
> >said
> >> >about
> >> >>>> anything.  I find this dismissive, and in this group,
> >unfortunately
> >> >I am
> >> >>>> left with the feeling of relatively little recourse.
> >> >>>>
> >> >>>> I will leave this thread open a while to gather feedback and I
> >> >think the
> >> >>>> advice is to document exactly what the concerns are and put them
> >in
> >> >a
> >> >>>> document, so they can be understood.  Which I have begun to do.
> >> >Much will
> >> >>>> depend on how much time I have to do this.
> >> >>>>
> >> >>>> So, I think the issue here is that there are a number of people
> >in
> >> >this
> >> >>>> group.  Some are coding regularly in this space, and some are
> >> >familiar with
> >> >>>> existing W3C standards that solve this problem, but few are
> >both.
> >> >So
> >> >>>> perhaps that can also be documented.
> >> >>>>
> >> >>>
> >> >>> To clarify this is not a "formal" objection, because:
> >> >>>
> >> >>> 1 It would need to be clearly documented
> >> >>> 2 It would need to be worthy of the attention of a wider audience
> >> >>> (director + w3c member) -- that's not clear to me at this point
> >> >>> 3 It would need fail to be resolved in the WG (I think we still
> >have
> >> >>> space to do that)
> >> >>>
> >> >>> I dont think 1/2/3 are currently met at this time.  So I will try
> >> >and
> >> >>> build out (1) because I think there are legitimate concerns
> >around
> >> >interop
> >> >>>
> >> >>> My recommendation at this point, is for this work to be a Note,
> >and
> >> >leave
> >> >>> the door open for further standardization.
> >> >>>
> >> >>>
> >> >>>>
> >> >>>>
> >> >>>>>
> >> >>>>> Another thing you could do is help move forward one of the
> >> >alternatives
> >> >>>>> to Webmention.    Rhiaro mentioned in #39 how activitypub might
> >be
> >> >just
> >> >>>>> what you want, and I understand there are several other
> >possible
> >> >directions
> >> >>>>> one could go.
> >> >>>>>
> >> >>>>> A few more comments below, but the important part of my reply
> >here
> >> >is
> >> >>>>> done.
> >> >>>>>
> >> >>>>> 1. Universality
> >> >>>>>
> >> >>>>> Axiom 0 of the webstates that we should use URIs to name
> >things.
> >> >>>>>
> >> >>>>>
> >> >>>>> I assume you're referring to TimBL's DesignIssues/Axioms
> >document?
> >> >>>>> That was written 20 years ago and reflects only one person's
> >> >opinion.   The
> >> >>>>> W3C Recommendation in this space, a few years later, which
> >> >resulted from
> >> >>>>> extensive discussion among TimBL, the appointed and elected
> >> >members of TAG,
> >> >>>>> and many members of the public, was AWWW.     I think you'll
> >find
> >> >AWWW
> >> >>>>> includes a rather more restrictive and realistic version of
> >this
> >> >axiom:
> >> >>>>>
> >> >>>>> 2.1. Benefits of URIs
> >> >>>>>
> >> >>>>> The choice of syntax for global identifiers is somewhat
> >arbitrary;
> >> >it
> >> >>>>> is their global scope that is important. The Uniform Resource
> >> >>>>> Identifier, [URI <https://www.w3.org/TR/webarch/#URI>], has
> >been
> >> >>>>> successfully deployed since the creation of the Web. There are
> >> >substantial
> >> >>>>> benefits to participating in the existing network of URIs,
> >> >including
> >> >>>>> linking, bookmarking, caching, and indexing by search engines,
> >and
> >> >there
> >> >>>>> are substantial costs to creating a new identification system
> >that
> >> >has the
> >> >>>>> same properties as URIs.
> >> >>>>>
> >> >>>>> Good practice: Identify with URIs
> >> >>>>>
> >> >>>>> To benefit from and increase the value of the World Wide Web,
> >> >agents
> >> >>>>> should provide URIs as identifiers for resources.
> >> >>>>>
> >> >>>>> A resource should have an associated URI if another party might
> >> >>>>> reasonably want to create a hypertext link to it, make or
> >refute
> >> >assertions
> >> >>>>> about it, retrieve or cache a representation of it, include all
> >or
> >> >part of
> >> >>>>> it by reference into another representation, annotate it, or
> >> >perform other
> >> >>>>> operations on it. Software developers should expect that
> >sharing
> >> >URIs
> >> >>>>> across applications will be useful, even if that utility is not
> >> >initially
> >> >>>>> evident. The TAG finding "URIs, Addressability, and the use of
> >> >HTTP
> >> >>>>> GET and POST
> ><http://www.w3.org/2001/tag/doc/whenToUseGet.html>"
> >> >discusses
> >> >>>>> additional benefits and considerations of URI addressability.
> >> >>>>> From https://www.w3.org/TR/webarch/
> >> ><https://www.w3.org/TR/webarch/>
> >> >>>>>
> >> >>>>> I think it's pretty hard to argue that the strings "source" and
> >> >>>>> "target" in Webmention posts should be URIs based on this
> >advice.
> >> > For the
> >> >>>>> cases where one would want them to be URIs, a standard mapping
> >is
> >> >>>>> provided.  You could view Webmention as using URIs for this,
> >but
> >> >during the
> >> >>>>> POST, the namespace is left implicit.
> >> >>>>>
> >> >>>>> Most standards I know at the W3C adhere to this,
> >> >>>>>
> >> >>>>>
> >> >>>>> Does HTML?   Does CSS?   Do any of the HTML5 APIs?    Can you
> >name
> >> >a
> >> >>>>> non-RDF spec that does?      Probably best to stay away from
> >XML
> >> >specs,
> >> >>>>> since their use of URIs is highly contentious.   (As I
> >understand
> >> >it, XML
> >> >>>>> only uses URIs as web addresses and unique identifiers, not to
> >> >name
> >> >>>>> things.   The difference is perhaps pedantic, but it's clear
> >XML
> >> >specs
> >> >>>>> don't align with the Linked Data Principles, which I think
> >TimBL
> >> >would
> >> >>>>> agree subsumes Axiom 0 in his own personal design sense.)
> >> >>>>>
> >> >>>>> Probably not worth the time to go through this, but if I had to
> >> >guess,
> >> >>>>> I'd say by count 10% of W3C specs adhere to this (my groups
> >like
> >> >RDF, OWL,
> >> >>>>> and RIF tended to produce a dozen specs at a time) and by user
> >> >base, 0.001%
> >> >>>>> of the W3C specs adhere to this.   The weight of success is not
> >on
> >> >the side
> >> >>>>> of this axiom, so it's not going to convince anyone.
> >> >>>>>
> >> >>>>> webmention does not use URIs for the source and target
> >parameters.
> >> >>>>>
> >> >>>>> URIs can be derived out of band by reading the spec and using a
> >> >prefix,
> >> >>>>> but this is not ideal.
> >> >>>>>
> >> >>>>>
> >> >>>>> Here's where, if you want to convince anyone, you have to tell
> >a
> >> >story
> >> >>>>> about something that's important and significantly easier with
> >> >source and
> >> >>>>> target being URIs on the wire.   I just don't see it.
> >> >>>>>
> >> >>>>>
> >> >>>>> 2. Using form encoded messaging for the social web
> >> >>>>>
> >> >>>>> Views on this differ, but IMHO it's very clear that messaging
> >over
> >> >the
> >> >>>>> social web according to our charter should be in JSON.
> >> >>>>>
> >> >>>>>
> >> >>>>> The chairs and I have addressed the charter issue elsewhere.
> >> >Please
> >> >>>>> keep charter discussions in separate threads, since they
> >involve
> >> >different
> >> >>>>> people and are reviewed differently.
> >> >>>>>
> >> >>>>> Webmention doesnt do this.
> >> >>>>>
> >> >>>>> To the extent that it's "just a signaling protocol" I suppose
> >you
> >> >could
> >> >>>>> "get away with it".  But I dont think webmention is by any
> >means
> >> >just a
> >> >>>>> signaling protocol.  It's an attempt to standardize messaging
> >on
> >> >the social
> >> >>>>> web.
> >> >>>>>
> >> >>>>>
> >> >>>>> How can you claim Webmention is "an attempt to standardize
> >> >messaging"?
> >> >>>>>   I don't see that in the spec.  I haven't heard that from the
> >WG.
> >> >  I
> >> >>>>> haven't heard that from the implementors.   I haven't heard
> >that
> >> >from the
> >> >>>>> users.   Where are you getting that?
> >> >>>>>
> >> >>>>> I do, however, see how it could be *used* as part of a general
> >> >>>>> messaging protocol:
> >> >>>>>
> >> >>>>> 1. System "Alice" wants to send system "Bob" some message M1
> >> >>>>> 2. Alice puts M1 on the web at URL U1, being sure to include
> >some
> >> >>>>> metadata the links to Bob.    At a minimum, something like "To:
> >> >Bob" (where
> >> >>>>> Bob is a URL)
> >> >>>>> 3. Alice does the Webmention thing, "mentioning" U1 to Bob
> >> >>>>> 4. Bob gets the mention, dereferences U1, reads M1
> >> >>>>>
> >> >>>>> So, in this sense, Webmention could be a key part of a web
> >> >messaging
> >> >>>>> protocol.   It's has one advantage over the much simpler
> >approach
> >> >of "Alice
> >> >>>>> POSTS M1 to Bob", namely that Alice is confirmed as the sender.
> >> >>>>>
> >> >>>>> But:
> >> >>>>> - This isn't what Webmention was designed for; it's not clear
> >> >anyone
> >> >>>>> actually wants to use it for this.
> >> >>>>> - If you do this, the actual message can be JSON or whatever
> >Alice
> >> >>>>> wants.   The *message* is M1, published at U1, *not* the
> >> >form-encoded
> >> >>>>> Webmention that was posted to Bob.
> >> >>>>> - If you want to do this, consider instead just POSTing M1 to
> >Bob
> >> >using
> >> >>>>> some kind of authentication for Alice (eg OpenID Connect or
> >> >WebID-TLS)
> >> >>>>>
> >> >>>>> So, I see no argument here against the current design of
> >> >Webmention.
> >> >>>>>
> >> >>>>>
> >> >>>>> Possible Solutions
> >> >>>>>
> >> >>>>> 1. Support JSON messaging -- the W3C has innovated in this area
> >> >with
> >> >>>>> some success
> >> >>>>>
> >> >>>>> 2. If we want to pass around messages using forms we should
> >make
> >> >the
> >> >>>>> general case robust, scalable, extensible, interoperable and
> >> >universal, and
> >> >>>>> have webmention be an instance of such a system.  That's
> >possibly
> >> >outside
> >> >>>>> the scope and timing of this WG, I dont know.
> >> >>>>>
> >> >>>>>
> >> >>>>> I'm not sure what those are solutions to, but they're probably
> >not
> >> >the
> >> >>>>> problems Webmention is intended to solve.
> >> >>>>>
> >> >>>>>
> >> >>>>> Im still being guided as to the difference between the REC and
> >> >Note
> >> >>>>> tracks, but I'll put the suggestion out there to move
> >webmention
> >> >to a note,
> >> >>>>> or move it back from CR.  I'm not an expert on this aspect of
> >W3C
> >> >process,
> >> >>>>> but I'd like to raise these concerns to a wider audience, in
> >> >particular, to
> >> >>>>> folks outside the indieweb community.
> >> >>>>>
> >> >>>>>
> >> >>>>> If you want people to pay attention to these concerns, either
> >> >inside or
> >> >>>>> outside the WG, I think you're going to have to develop a
> >simple
> >> >story
> >> >>>>> about a problem that's solved with your modified Webmention and
> >> >not solved
> >> >>>>> with Webmention.   Or a story about how Webmention being
> >adopted
> >> >would do
> >> >>>>> real harm to someone.
> >> >>>>>
> >> >>>>> Frankly, I think you can find much better uses for your time if
> >> >you
> >> >>>>> want to work in this space, eg helping with activitypub.
> >> >>>>>
> >> >>>>>         -- Sandro
> >> >>>>>
> >> >>>>
> >> >>>>
> >> >>>
> >>
> >>
>
>