Re: Ecosystem issues for JSON-LD 1.1

Rob,

all these are extremely sound considerations. In practice, what we may need to do at the beginning of the WG's life is to systematically go through the JSON-LD 1.1 draft with a fresh eye (I would expect/hope the WG will include people who are not CG members) mainly in view of your second point below: look at all new features and the reasons and use cases that led to them, to argument the pros and cons of those.

The common crawl idea is also very interesting. What this tells me is that we will have to talk about the testing approaches right on the first day, to see how we would go along this. The life-span of the WG is not very long, meaning that the CR phase will be upon us before we know it:-)

Thanks for this

Ivan

> On 24 Apr 2018, at 20:22, Robert Sanderson <azaroth42@gmail.com <mailto:azaroth42@gmail.com>> wrote:
> 
> Dear all,
> 
> The following issues came out of a discussion with Dan Brickley of Google and Charles McCathie Neville recently of Yandex last week.  This is my summary, and does not necessarily reflect the opinions of Dan or Chaals, or their employers.
> 
> * Practical backwards compatibility with 1.0
> It is important to ensure that the next version of the specification is backwards compatible with the current 1.0.  There are hundreds of millions of sites using JSON-LD 1.0 that we cannot afford to invalidate over night.  Processing a 1.0 context in a 1.1 environment should have the same results, in practice even if there are bugs in the 1.0 spec that get fixed.  Or, another way, if schema.org <http://schema.org/> put @context:1.1 in their context document, no one should really notice. One idea was to scrape the JSON-LD out of the Common Crawl [1], and use it as a testbed for validating the effects of algorithmic changes in practice.  Any incompatibilities need to be very carefully considered with strong justification.
> 
> * Complexity / Value
> As with any transformation or mapping language (comparisons were drawn with GRDDL [2] and XSLT [3]), there is a trade off between complexity and expressivity.  As we add more features to the @context mapping language, we add the ability to express further use cases, but at the cost of fewer complete implementations.  This can be managed in several ways, including structured documentation and explicitly calling out what systems MUST or SHOULD implement and the consequences of not doing so, however better yet is to not add the complexity in the first place.  A systemic approach to evaluating the costs and advantages of adding features should be adopted for the working group. Each feature should have stronger use cases for when it is important to use, rather than just examples of its use.
> 
> * Context Best Practices in a Distributed Ecosystem
> Regardless of the functionality available, how _should_ contexts be deployed that take into account the wide variety of use cases and environments? This needs to encompass the possibility that browsers would process JSON-LD embedded in HTML to make additional functionality available for the use. Consider the gmail (and now in Outlook) email actions [4] ... but encountered in pages by the browser.  If contexts are to matter beyond a flag for further processing, there needs to be a method for not performing a massive denial of service attack on an unsuspecting server as every web browser suddenly starts pinging it for its context.
> 
> As we move towards a new Working Group, these sorts of systemic issues should be taken into account as well as the details of the algorithms and context/framing description languages.
> 
> Thoughts on these sorts of issues would be appreciated!
> 
> Rob
> 
> --
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049


----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: https://orcid.org/0000-0003-0782-2704 <https://orcid.org/0000-0003-0782-2704>