Conforming WebSub subscriberはHTMLの`link`要素を確認しなくてはならない（MUST）（<https://www.w3.org/TR/websub/#x4-discovery>）などと簡単に言ってくれるなという気持ちに苛まれている
Conforming WebSub subscriberはHTMLの`link`要素を確認しなくてはならない（MUST）（<https://www.w3.org/TR/websub/#x4-discovery>）などと簡単に言ってくれるなという気持ちに苛まれている
Atom/RSSのようなXMLベースのトピックのみを扱うケースが多いだろうにHTMLパーサを持つことが必須なのは過剰では。少なくともコンテンツ交渉でHTMLを要求していなかった場合には無視できても良いと思うのよね
`rel="alternate"`を探すためにHTMLを読むケースはあるかもしれないけど、`alternate`の扱いはWebSubのスコープ外のようだし
これがアプリケーションなら合理的と信じる範囲で多少の適合性を犠牲にする手もあるのだろうけど、今回はライブラリとして切り出しているところなのでそうも行かない
というわけで取りあえずHTMLのパースも実装するとして、クレートフィーチャとしてユーザの判断で無効にできるようにしようかなと
ついでにディスカバリのロジックは`tower_service::Service`として抽象化してユーザが定義できるようにもしたい。アプリケーションによって`<head>`以下だけ読みたい／`<body>`以下も読みたいといった細かい要件があるだろうし、例えばJSON Feedのようなエキゾチックな書式からディスカバリを行いたいこともあるかもしれないので
`<link>`を探すだけならまともにDOMツリーを構築する必要もないだろうし、簡単な`html5ever::tree_builder::TreeSink`実装を作るだけで済むだろう……多分
W3C blog: "Answering 'What ARIA can I use?'" by Matthew King
“Assistive Technology Support” tables in the ARIA Authoring Practices Guide show how 3 screen readers support 4 UI pattern implementations represents a sea change in accessibility engineering
https://www.w3.org/blog/2023/04/answering-what-aria-can-i-use/
しょうもないバグを埋め込んでしまったコードやそのコメントを振り返ると、LLMの一見尤もらしいhallucinationを読まされているような気分になってくる