Re: Proposed W3C Charter: JSON-LD Working Group

[Benjamin Francis]

Thank you for looping me in.

It's probably worth mentioning that some proposed features for JSON-LD 1.1
may actually help us to keep JSON-LD *out* of the Web of Things
specifications, or at least make it an optional mechanism for adding
semantic annotations to an otherwise plain JSON serialisation [1] of the
Thing Description format [2] (like adding semantic annotations to HTML).

The rigid representation of RDF triples in JSON-LD 1.0 imposes significant
constraints on the design of a JSON-based format if consumers want to be
able to optionally parse it as JSON-LD (which many members of the Web of
Things Working Group feel strongly that they do). Features proposed for
JSON-LD 1.1 would allow much more flexibility to create a simpler and more
intuitive plain JSON serialisation (e.g. using JSON objects instead of
arrays in various places), with an implied default context, which can still
optionally have semantic annotations added if someone wants to do that.

These proposed JSON-LD 1.1 features have enabled us to successfully argue
for a plain JSON serialisation instead of the current JSON-LD
serialisation, while not fragmenting the Web of Things effort.

I understand there are arguments against resources which can be parsed both
as plain JSON and as JSON-LD, but there are lots of use cases people have
for adding semantic annotations to JSON. Supporting (or at least not
objecting to) the charter for JSON-LD 1.1 may actually help keep JSON-LD
out of the web platform by making it an optional extension, rather than a
dependency, in specifications.

Note that we've gone to great lengths to keep JSON-LD out of our Web of
Things proposal [2] so far, but I think it's probably inevitable that we're
eventually going to need some kind of lightweight extensible schema based
system for describing things in the real world, in order to make ad-hoc
interoperability possible. Hopefully something lightweight like Open Graph
or Microformats rather than a heavyweight solution like full JSON-LD (I'd
value input on that [3]). Currently a leading effort in that area is
iotschema.org which, like schema.org, will probably support JSON-LD style
annotations using @context and @type.

I should also probably mention the Web of Things specifications don't
require any implementation in web browsers, we're using it as an entirely
server side technology, so this work has no impact on Firefox.

By all means feel free to express your grumbles with JSON-LD, but note that
JSON-LD 1.1. could actually be a positive step forward for some Mozilla
efforts.

Thanks

Ben

1. Our proposed plain JSON serialisation of a Thing Description
https://iot.mozilla.org/wot
2. Current W3C Thing Description specification with JSON-LD serialisation
https://w3c.github.io/wot-thing-description/
3. Discussion on a schema based "capabilities" system for the Web of Things
https://github.com/mozilla-iot/wot/issues/57

On 30 April 2018 at 16:16, Peter Saint-Andre  wrote:

> On 4/29/18 10:42 AM, Henri Sivonen wrote:
> > On Sun, Apr 29, 2018, 19:35 L. David Baron  wrote:
> >
> >> OK, here's a draft of an explicit abtension that I can submit later
> >> today.  Does this seem reasonable?
> >>
> >
> > This looks good to me. Thank you.
>
> +1
>
> We might want to also check in with folks who are involved with the
> relevant WGs (e.g., Ben Francis, cc'd, w.r.t. Web of Things). I'll
> forward to him Tantek's earlier message.
>
> Peter
>
> >
> >
> >
> >>
> >> One concern that we've had over the past few years about JSON-LD
> >> is that some people have been advocating that formats adopt
> >> JSON-LD semantics, but at the same time allow processing as
> >> regular JSON, as a way to make the adoption of JSON-LD
> >> lighter-weight for producers and consumers who (like us) don't
> >> want to have to implement full JSON-LD semantics.  This yields a
> >> format with two classes of processors that will produce different
> >> results on many inputs, which is bad for interoperability.  And
> >> full JSON-LD implementation is often more complexity than needed
> >> for both producers and consumers of content.  We don't want
> >> people who produce Web sites or maintain Web browsers to have to
> >> deal with this complexity.  For more details on this issue, see
> >> https://hsivonen.fi/no-json-ns/ .
> >>
> >> This leads us to be concerned about the Coordination section in
> >> the charter, which suggests that some W3C Groups that we are
> >> involved in or may end up implementing the work of (Web of
> >> Things, Publishing) will use JSON-LD.  We would prefer that the
> >> work of these groups not use JSON-LD for the reasons described
> >> above, but this charter seems to imply that they will.
> >>
> >> While in general we support doing maintenance (and thus aren't
> >> objecting), we're also concerned that the charter is quite
> >> open-ended about what new features will be included (e.g.,
> >> referring to "requests for new features" and "take into 

Re: Proposed W3C Charter: JSON-LD Working Group

[Peter Saint-Andre]

On 4/29/18 10:42 AM, Henri Sivonen wrote:
> On Sun, Apr 29, 2018, 19:35 L. David Baron  wrote:
> 
>> OK, here's a draft of an explicit abtension that I can submit later
>> today.  Does this seem reasonable?
>>
> 
> This looks good to me. Thank you.

+1

We might want to also check in with folks who are involved with the
relevant WGs (e.g., Ben Francis, cc'd, w.r.t. Web of Things). I'll
forward to him Tantek's earlier message.

Peter

> 
> 
> 
>>
>> One concern that we've had over the past few years about JSON-LD
>> is that some people have been advocating that formats adopt
>> JSON-LD semantics, but at the same time allow processing as
>> regular JSON, as a way to make the adoption of JSON-LD
>> lighter-weight for producers and consumers who (like us) don't
>> want to have to implement full JSON-LD semantics.  This yields a
>> format with two classes of processors that will produce different
>> results on many inputs, which is bad for interoperability.  And
>> full JSON-LD implementation is often more complexity than needed
>> for both producers and consumers of content.  We don't want
>> people who produce Web sites or maintain Web browsers to have to
>> deal with this complexity.  For more details on this issue, see
>> https://hsivonen.fi/no-json-ns/ .
>>
>> This leads us to be concerned about the Coordination section in
>> the charter, which suggests that some W3C Groups that we are
>> involved in or may end up implementing the work of (Web of
>> Things, Publishing) will use JSON-LD.  We would prefer that the
>> work of these groups not use JSON-LD for the reasons described
>> above, but this charter seems to imply that they will.
>>
>> While in general we support doing maintenance (and thus aren't
>> objecting), we're also concerned that the charter is quite
>> open-ended about what new features will be included (e.g.,
>> referring to "requests for new features" and "take into account
>> new features and desired simplifications that have become
>> apparent since its publication").  As the guidance in
>> https://www.w3.org/Guide/standards-track/ suggests, new features
>> should be limited to those already incubated in the CG.  (If we
>> were planning to implement, we might be objecting on these
>> grounds.)
>>
>>
>> -David
>>
>> --
>> 턞   L. David Baron http://dbaron.org/   턂
>> 턢   Mozilla  https://www.mozilla.org/   턂
>>  Before I built a wall I'd ask to know
>>  What I was walling in or walling out,
>>  And to whom I was like to give offense.
>>- Robert Frost, Mending Wall (1914)
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: JSON-LD Working Group

[Henri Sivonen]

On Sun, Apr 29, 2018, 19:35 L. David Baron  wrote:

> OK, here's a draft of an explicit abtension that I can submit later
> today.  Does this seem reasonable?
>

This looks good to me. Thank you.



>
> One concern that we've had over the past few years about JSON-LD
> is that some people have been advocating that formats adopt
> JSON-LD semantics, but at the same time allow processing as
> regular JSON, as a way to make the adoption of JSON-LD
> lighter-weight for producers and consumers who (like us) don't
> want to have to implement full JSON-LD semantics.  This yields a
> format with two classes of processors that will produce different
> results on many inputs, which is bad for interoperability.  And
> full JSON-LD implementation is often more complexity than needed
> for both producers and consumers of content.  We don't want
> people who produce Web sites or maintain Web browsers to have to
> deal with this complexity.  For more details on this issue, see
> https://hsivonen.fi/no-json-ns/ .
>
> This leads us to be concerned about the Coordination section in
> the charter, which suggests that some W3C Groups that we are
> involved in or may end up implementing the work of (Web of
> Things, Publishing) will use JSON-LD.  We would prefer that the
> work of these groups not use JSON-LD for the reasons described
> above, but this charter seems to imply that they will.
>
> While in general we support doing maintenance (and thus aren't
> objecting), we're also concerned that the charter is quite
> open-ended about what new features will be included (e.g.,
> referring to "requests for new features" and "take into account
> new features and desired simplifications that have become
> apparent since its publication").  As the guidance in
> https://www.w3.org/Guide/standards-track/ suggests, new features
> should be limited to those already incubated in the CG.  (If we
> were planning to implement, we might be objecting on these
> grounds.)
>
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: JSON-LD Working Group

[Tantek Çelik]

This looks good and clearly covers all the concerns we discussed. Thanks
for writing this up.

If possible let’s make our answers public on this so we may more easily
cite them in other discussions. This isn’t the last we’ve seen of the quiet
attempts to JSON-LDify the web platform.

-Tantek

On Sun, Apr 29, 2018 at 09:35 L. David Baron  wrote:

> OK, here's a draft of an explicit abtension that I can submit later
> today.  Does this seem reasonable?
>
>
> One concern that we've had over the past few years about JSON-LD
> is that some people have been advocating that formats adopt
> JSON-LD semantics, but at the same time allow processing as
> regular JSON, as a way to make the adoption of JSON-LD
> lighter-weight for producers and consumers who (like us) don't
> want to have to implement full JSON-LD semantics.  This yields a
> format with two classes of processors that will produce different
> results on many inputs, which is bad for interoperability.  And
> full JSON-LD implementation is often more complexity than needed
> for both producers and consumers of content.  We don't want
> people who produce Web sites or maintain Web browsers to have to
> deal with this complexity.  For more details on this issue, see
> https://hsivonen.fi/no-json-ns/ .
>
> This leads us to be concerned about the Coordination section in
> the charter, which suggests that some W3C Groups that we are
> involved in or may end up implementing the work of (Web of
> Things, Publishing) will use JSON-LD.  We would prefer that the
> work of these groups not use JSON-LD for the reasons described
> above, but this charter seems to imply that they will.
>
> While in general we support doing maintenance (and thus aren't
> objecting), we're also concerned that the charter is quite
> open-ended about what new features will be included (e.g.,
> referring to "requests for new features" and "take into account
> new features and desired simplifications that have become
> apparent since its publication").  As the guidance in
> https://www.w3.org/Guide/standards-track/ suggests, new features
> should be limited to those already incubated in the CG.  (If we
> were planning to implement, we might be objecting on these
> grounds.)
>
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: JSON-LD Working Group

[L. David Baron]

OK, here's a draft of an explicit abtension that I can submit later
today.  Does this seem reasonable?


One concern that we've had over the past few years about JSON-LD
is that some people have been advocating that formats adopt
JSON-LD semantics, but at the same time allow processing as
regular JSON, as a way to make the adoption of JSON-LD
lighter-weight for producers and consumers who (like us) don't
want to have to implement full JSON-LD semantics.  This yields a
format with two classes of processors that will produce different
results on many inputs, which is bad for interoperability.  And
full JSON-LD implementation is often more complexity than needed
for both producers and consumers of content.  We don't want
people who produce Web sites or maintain Web browsers to have to
deal with this complexity.  For more details on this issue, see
https://hsivonen.fi/no-json-ns/ .

This leads us to be concerned about the Coordination section in
the charter, which suggests that some W3C Groups that we are
involved in or may end up implementing the work of (Web of
Things, Publishing) will use JSON-LD.  We would prefer that the
work of these groups not use JSON-LD for the reasons described
above, but this charter seems to imply that they will.

While in general we support doing maintenance (and thus aren't
objecting), we're also concerned that the charter is quite
open-ended about what new features will be included (e.g.,
referring to "requests for new features" and "take into account
new features and desired simplifications that have become
apparent since its publication").  As the guidance in
https://www.w3.org/Guide/standards-track/ suggests, new features
should be limited to those already incubated in the CG.  (If we
were planning to implement, we might be objecting on these
grounds.)


-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: JSON-LD Working Group

[Tantek Çelik]

On Fri, Apr 27, 2018 at 2:09 PM, Adam Roach  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 

Re: Proposed W3C Charter: JSON-LD Working Group

[L. David Baron]

On Friday 2018-04-27 16:09 -0500, Adam Roach wrote:
> 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.

I think the issue is that *some* of the users of the specification
are doing this.  I think we should strongly object to specifications
that use it that way... but I still find it hard to formulate an
objection to JSON-LD itself.  (Especially for relatively small
maintenance to the spec.)

I think an analogy to what's happening would be to specs claiming to
use XML namespaces, but some of them relying on the tag being
"html:select" rather than doing processing of the xmlns attributes
to figure out what the "html:" (or "xhtml:", etc.) prefix means.
Except that in this case it's a more complicated thing than XML
namespaces:  the full RDF data model.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: JSON-LD Working Group

[Adam Roach]

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. 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, 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 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).

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.

I'm inclined to leave this one alone, unless somebody else comes up
with a better position we could take.


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.


/a
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: JSON-LD Working Group

[L. David Baron]

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. 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, 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 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).

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.

I'm inclined to leave this one alone, unless somebody else comes up
with a better position we could take.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: JSON-LD Working Group

[Henri Sivonen]

On Fri, Apr 27, 2018 at 1:04 AM, L. David Baron  wrote:
> The W3C is proposing a charter for:
>
>   JSON-LD Working Group
>   https://www.w3.org/2018/03/jsonld-wg-charter.html
>   https://lists.w3.org/Archives/Public/public-new-work/2018Mar/0004.html
>
> Mozilla has the opportunity to send comments or objections through
> Sunday, April 29.  (Sorry for failing to send this out sooner!)
>
> This is a charter to produce JSON-LD 1.1 (A JSON-based Serialization
> for Linked Data), which is a revision of JSON-LD 1.0, which was
> developed under the now-closed RDF Working Group.  The
> specifications proposed in a charter have been developed in a
> community group.
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.

JSON-LD's compatibility with the RDF data model and the fundamental
principle that identifiers expand to URIs means that JSON-LD
perpetuates the fundamental ergonomic problem of RDF. All
serializations of RDF, JSON-LD included, try to take steps to
alleviate the visibility of the problem on the syntax level but none
can git rid of the problem on the data model layer (since they
subscribe to the fundamental principle that is the source of the
problem and don't break data model compatibility). Thus, code that
processes the formats either has to be unergonomic or incorrect. It's
bad to have specs that promote unergonomic or incorrect
implementations and especially the mutually-incompatible co-existence
of the two.

See https://hsivonen.fi/no-json-ns/ for an elaboration--especially the
epilog. JSON-LD evangelism, including the slides linked to from the
charter (slide 3), tends to be about selling the format by claiming
that developers can ignore the RDF/URI stuff (i.e. write code that's
incorrect in terms of the full processing model). The very last
section of https://hsivonen.fi/no-json-ns/ addresses this based on
experience from Web-scale formats.

For this reason, I think we should resist introducing dependencies on
JSON-LD in formats and APIs that are relevant to the Web Platform. 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, 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 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).

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform