Re: Proposed W3C Charter: JSON-LD Working Group
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
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
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: PSA: new CopyableErrorResult class
On 04/27/2018 12:14 AM, Ben Kelly wrote:
Hi all,
I just pushed another helper class that I thought others might find useful.
CopyableErrorResult is a specialized form of ErrorResult. Its intended to
allow slightly more rich error values to be passed through things like ipdl
structure and MozPromise. This is useful when implementing web exposed
features that need to execute code in the parent process and surface useful
TypeError messages back to the page. A simple nsresult loses the developer
friendly messages. If you are building something like this, then you might
want to consider CopyableErrorResult.
If in doubt, though, please use ErrorResult itself. It has stricter
checking and should be preferred. Particularly if there is any chance the
error might contain a js exception.
The CopyableErrorResult has a few properties:
1. Asserts if you try to store a js exception. It may only contain simple
errors or errors with messages. In release builds it converts the js
exception to an NS_ERROR_FAILURE.
2. Has a copy constructor, assignment operator, etc.
3. May be safely transferred across threads.
4. Automatically suppresses errors instead of asserting if its not consumed.
Hmm, (4) is worrisome. The name of the class doesn't hint this kind of behavior,
and we have IgnoredErrorResult.
Why does CopyableErrorResult have this behavior? I understand not asserting if
the error was copied from some other ErrorResult to a CopyableErrorResult
instance,
but shouldn't we assert if that didn't happen?
These are significant because they mean you can create an ipdl structure or
union type that contains a CopyableErrorResult. This is not possible with
an ordinary ErrorResult because there is no copy constructor, etc.
It is safer to use CopyableErrorResult in a MozPromise reaction because its
thread safe and does not assert if its destroyed before consumed. These
are important because MozPromise reactions can cross thread boundaries and
a disconnected promise may not consume its reaction value, etc.
Using CopyableErrorResult allows you to provide error messages along with
TypeError, etc. Passing just an nsresult provides a worse developer
experience for webdevs.
One quirk you may run into is that CopyableErrorResult may not be used as a
value argument to a method. This is because it contains a js MOZ_NON_PARAM
value in a union type even through it does runtime checking to avoid ever
actually using that type. To work around this you do this:
DoFoo(const CopyableErrorResult& aRv) {
ConsumeResult(CopyableErrorResult(aRv));
}
This is often needed in MozPromise reaction handlers.
Please let me know if you run into any problems.
Thanks.
Ben
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
