On Fri, Apr 27, 2018 at 2:09 PM, Adam Roach <a...@mozilla.com> wrote: > On 4/27/18 2:02 PM, L. David Baron wrote: >> >> On Friday 2018-04-27 10:07 +0300, Henri Sivonen wrote: >>> >>> For this reason, I think we should resist introducing dependencies on >>> JSON-LD in formats and APIs that are relevant to the Web Platform.
Agreed with Henri summary criticism and have been warning as much (re: introducing dependencies on JSON-LD) for a few years. The specific concern to call out in the charter is only implied by the Coordination section: https://www.w3.org/2018/03/jsonld-wg-charter.html#w3c-coordination In particular we could state some concern about these which will likely impact our (Mozilla) products: "* Web of Things Working Group" (though I am unsure if "that ship has sailed" or not - that is, I have not dug deep enough to determine if WoT work is actively dependent on JSON-LD, heading that way, or not at all yet) " * Publishing Working Group The Publishing Working Group is considering using JSON-LD as a serialization format for various types of metadata for Web Publications, as well as a serialization format for the Web Publication Manifest. " Nevermind a separate Web Publication Manifest from Web App Manifest (which itself is an issue, cc Marcos), it is likely that Firefox will end up having to support whatever Web Publication format(s) come out of W3C, thus we should be actively advocating for something that does not need JSON-LD. >>> I >>> think it follows that we should not support this charter. I expect >>> this charter to pass in any case, so I'm not sure us saying something >>> changes anything, At a minimum we should explicitly Abstain in our review, with comments. The other reasonable option is a non-formal objection. >>> but it might still be worth a try to register >>> displeasure about the prospect of JSON-LD coming into contact with >>> stuff that Web engines or people who make Web apps or sites need to >>> deal with Yes we should register our displeasure, and it is not just a "prospect", there are (problem) examples already, most notably due to Google Search side latest syntax du jour for serp rich snippets being JSON-LD data islands in HTML. The stats for JSON-LD adoption are essentially all publishing, primarily for Google Search's opaque consumption. * SEO types putting JSON-LD into HTML documents, with no way to verify any actual processing impact / results (validators exist to check syntax, but not show impact on actual results to users). Aside: Google Search has cycled through recommending Google Base, GData XML, microformats, RDFa, microdata, JSON-LD all in the past, without technical reasons or evidence and yet still supports most of what they supported in the past: https://aaronparecki.com/2016/12/17/8/owning-my-reviews#historical-recommendations There is no actual "need" for JSON-LD in practice for the Google/Search SEO "use-case". >>> and to register displeasure with designing formats whose >>> full processing model differs from how the format is evangelized to >>> developers (previously: serving XHTML as text/html while pretending to >>> get benefits of the XML processing model that way). This is a very good way of communicating the problem. The dual message of: * You can treat it just as a subset of JSON * If you want extra features if you have to parse it as JSON-LD Has had problems with such extra features in practice, especially in any ecosystem attempting to evolve extensions (supposedly one benefit of JSON-LD) across implementations, with forward/backward compatibility etc. (Do you update the @context file in-place or use a new @context? When do you update? What about implementations that include @context information "at compile time" Etc.) >> Yeah, I'm not quite sure how to register such displeasure. In >> particular, I think it's probably poor form to object to maintenance >> work on a base specification, even if we're opposed to that >> specification's use elsewhere. At least, assuming we don't want to >> make the argument that the energy being spent on that maintenance >> shouldn't be. On the flip side, from what I've seen, non-trivial maintenance and extensibility issues have been found with JSON-LD due to implementation feedback and iteration. In as much as there's a group of folks willing to do this maintenance, it seems prudent to let them do so, presuming the cost to W3C staff is minimal (I saw 0.1 but am not sure if I believe that). >> I'm inclined to leave this one alone, unless somebody else comes up >> with a better position we could take. I think we should register an explicit Abstain, and state our concerns that Henri summarized, our "displeasure about the prospect of JSON-LD coming into contact with stuff that Web engines or people who make Web apps or sites need to deal with", and make that public. Things we could object to: * Seemingly open ended "new features" as referred to in the charter. The charter refers to "requests for new features" and "take into account new features and desired simplifications that have become apparent since its publication" which are far too open ended. These new features should be limited to what the CG has already incubated per the guidance in the Rec Track Readiness document. Not sure if this is worth fighting for, but may be worth raising as a concern in our "abstention" (noting that we don't plan to implement, rather if we were, we would be objecting) On Fri, Apr 27, 2018 at 2:09 PM, Adam Roach <a...@mozilla.com> wrote: > > With the caveat that I have very limited knowledge about JSON-LD and am > basing this mostly on the preceding exchange: > > If there's a set of behaviors defined by the 1.0 spec, and a different set > of behaviors implemented, deployed, and evangelized, I think it would be > reasonable to object (on that basis) to a charter that does not explicitly > include work items to bring the spec into line with reality. They do explicitly include: * The Working Group will also handle all the errata filed for JSON-LD 1.0. * The Working Group will also handle all the errata filed for JSON-LD 1.0 API. Which presumably would handle differences in behaviors of JSON-LD processors from the spec, but not "plain JSON" processors. Thus I doubt that (or anything in charter) will address the "dual story" that Henri is referring to. Tantek _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
