proposal-is-usv-string
proposal-is-usv-string copied to clipboard
Stay reasonably neutral in problem statement
Given the long history of controversy around the topic, I think the problem statement reads somewhat tendentious and thus can be misunderstood as unalterable facts, which in part is not the case.
In particular, the Component Model's choice to only support USVString is called a requirement herein, even though the Component Model is merely in phase 1, is about to be formally objected to with the next phase advancement, and could trivially support DOMString as well (adhering to precedents like WebIDL, JSON, the many language standards etc.) so Java-like languages are not unnecessarily confronted with friction when interfacing with JS, themselves or each other. Some people, including myself, consider the Component Model's choice as arbitrary for this reason, as it really inserts conceptional discontinuity in between two things that would otherwise work just fine if DOMString was supported, which would significantly reduce the scope this proposal has to cover.
I hence propose to remain neutral in the problem statement, including that prior discussion is taken into account and people don't have a reason to feel too strongly over the reasoning.
Thinking a bit more about how to deal with differing strong opinions in a neutral way, I think there are two valid options:
- Balance: Briefly summarize both opinions if the context is considered noteworthy.
- Abstention: Do not mention either opinion and phrase very carefully so nothing is implied.
I've tried to adhere to these in my latest edit and am looking forward to your suggestions if you think there are further improvements.
@dcodeIO I think you're overthinking things. The purpose of this explainer is to make a compelling argument for the utility of the proposed features. The level of nuance you're looking to include here doesn't seem like it would help with that, and may, in its verbosity, actually take away from it. I'm willing to make the changes we discussed above if you would still prefer that to the current text. Otherwise I'm inclined to stop trying to resolve this concern and either leave the README as-is or remove all mentions of wasm/wasi. I'm confident that this proposal is sufficiently motivated even in their absence.
Please allow me a little more time to figure out if I can come up with a different structure respectively a shortened account, as I am so far not seeing any suggestions or discussions that would contribute to the title respectively intent of the PR. An alternative approach might be that additional context is moved to the FAQ, so related questions are reasonably answered. Would this be something you'd be comfortable with?
@dcodeIO Sure, let me know when you'd like another review, but please keep in mind the purpose of the explainer.