Well, we have seen something like this failing about six years ago.
Let's see whether
- there is a new killer-use-case or
- technology has advanced enough to make it less cumbersome or
- Apple can generate enough hype around it to make it work on its own.
SemBr author here. I chose SHOULD NOT for this rule for a couple reasons: First, as an affordance for text with ambiguous or unknown meaning. Second, as a hedge against introducing new meaning unintentionally.
Adding a semantic line break inherently changes the relationship between words, and we can't always be sure about the intended meaning of text. If this were MUST NOT, then any modification would risk violating the spec.
Then again, this may be my own, idiosyncratic reading of RFC 2119. If you'd like to discuss this further, feel free to open an issue on the GitHub repo here: https://github.com/sembr/specification/issues
I completely agree.
Using one line per sentence (and soemtime more lines when the sentence is longer)
makes it way easier to structure the text.
Markdown and are perfectly able to fit the text to the device you are reading on.
It also makes version control and diffs more usable.
However, I can also agree that this style might be not suitable for non-technical writing.
It is rally terrible that such a service is actually necessary...
PSD2 was a chance to create a standard api for everyone including customers. I still cannot understand how they managed to f it up by limiting access to "trusted companies"
I work at a bank and it's quite simple really. The systems we use at my workplace are so antiquated and wonky that even giving people read access would be a monumental effort. To put it plainly, modernizing these systems takes effort similar in order of magnitude to landing on the moon. Not for any technical reason, but due to the mountains of manual processes and general cruft built up around them. The EU is not deaf to these concerns, and therefore the laws end up falling short for no other reason than that they want someone to actually be able to follow them.
We are talking about things like "make a request at the wrong time and the system will be broken for the next 24 hours, and you are not allowed to speak to the people who know why".
People (myself included until a few years ago) buy into this "banks need to be secure and move slowly to maintain that" but really most of it is due to mismanagement. The "move slowly" is a rationalization.
Oh, I totally agree (started my carreer in a company that still used VSE/ESA and CICS and sometimes dream about ASRAs).
However, they had to implement modern api-stuff with PSD2 and then they made it strictly b2b-only :-(
Oh I think its a mix of both. But I do not have your insight ofc, so just guessing.
I think banks should move slowly and pay extra attention to security. Examples like N26 show that not doing so can cause significant issues.
But its also a great excuse to justify your vintage cruft.
