- my whistle setup (tested can run on echo show with <1s response): 206 correct out of 208
These were not tested on echo show yet - on my pc for now:
- Vosk small, phrase grammar: 184/208
- Speech-to-Phrase 1.4.3 (Kaldi): 118/208
- suggested sphinx: 63/208 and on some examples took 13s on i7 14700k pc
looks like my customized whistle works better for me than these alternatives. But more testing wouldn't hurt.
XML Web Services were awesome, but the SOAP and XML (where the hard parts that should have been given some batteries included defaults) I think was too much of a boat anchor to overcome.
And then the ruby/rails wave came and made 'rest' JSON the Silicon Valley hearthrob, and WSDLs were out like yesterdays trash.
Are they still used in businesses IRL? Yes! I worked for one that has probably (probably) moved off of them by now, but as recently as 2023 there were still some bank-facing power with SOAP RPC .asmx endpoint servers.
I follow hypermedia.systems and htmx/datastar/alpine.js because I'm still trying to get back that powerful _web_ tech advancement rather than squeezing everything into the javascript client side workaround. Typescript is great, a good poor man's F# and leagues ahead of ES3 (which I dabbled in / torture LLMs with so my old retrocomputers can still do web things), but its still bringing along so much baggage that could be lighter weight for older devices AND fits the tech utopianist promise of the original web (which is half of why I play with computer stuff).
By law, every single government form you're able to file is supposed to have an XML Schema available in a centralized registry. This regulation is widely ignored in practice, particularly by local / municipal governments.
This used to be more important in the past, as such a form could automatically / semi-automatically get an entry in the EPUAP form catalog and be made electronically fillable (EPUAP being the now-deprecated centralized government bureaucracy portal basically). As far as I understand, the way that worked was through XSLT and XML Forms. There was some weirdness about each document having a fillable / form view and a preview, I think XML Forms was somehow used to generate the XHTML form, while the XSLT sheet could only generate an XHTML preview of a complete, filled-in version. There were also some custom annotations for auto-fill and such, that was partly done by most documents relying on standardized schemas for entities like "person", "address" or "company".
Since we moved to E-Deliveries and lost a central place for these forms to live in, this is (AFAIK) a bit less important and less common, but internally, things are still XML. If you're filing something like an ID renewal application, even through a newer, more user-friendly frontend, it's still just XML underneath. If you sign something through podpis.gov.pl (the standardized e-signature solution for government paperwork), you can even download that underlying document, both signed and unsigned, and see what that XML is. The pre-signing document preview generated by that site still comes from the XSLT I believe. The signatures themselves are, unsurprisingly, also done via the XML signatures spec.
Incidentally, the European E-Delivery system itself also relies on XML, WSDL and Soap pretty heavily. For those unfamiliar and/or not in Europe, it's basically "email but for the government", with all the guarantees and legal obligations of physical mail, cryptographically-attested confirmation of receipt, proper identity verification and assurance, cross-provider address portability, deployed to a lesser or greater extend in many EU countries and set to replace physical mail.