Re: [Caml-list] [ANN] Lambda Soup - HTML scraping and rewriting with CSS selectors

[Drup <drupyog+caml@zoho.com>]

There seems to be a slight misunderstanding about how tyxml is 
constructed, so let me clarify things a bit.

- Tyxml doesn't have a canonical xml datatype, it's functorized over a 
generic Xml signature (implemented in [Xml_sigs.T]). As far as tyxml is 
concerned, xml nodes are a fully abstract type and can only be 
constructed. Multiple modules implements this signature in the ocsigen 
stack (two in js_of_ocaml's Tyxml_js, tree in eliom) that presents 
different characteristics. In particular some of them are really 
abstracts (React signals ...) and I doubt you could construct selectors 
over them in a meaningful way (but I would be happy to be proven wrong).
- Another signature, [Xml_sigs.ITERABLE], implement global iteration 
over xml trees. It is not necessary for an XML implementation used by 
tyxml to respect it and, in particular, it is not implemented for 
js_of_ocaml's Tyxml_js. As pointed out previously, it doesn't make sense 
for all implementations, but we could implement it for some of them.
- There is no signature for mutation (at the moment). This may be an 
interesting improvement.
- The [Xml] module implements a "bare" XML datatype that is not really 
used by ocsigen, but can be used to build simple xml trees in a typeful 
manner (and then print them). It also answers ITERABLE.

Now, in order to type lambda_soup using tyxml's types: It's going to be 
a bit of work. You can perfectly reuse all tyxml's type, but you need 
typeful combinators instead of strings, otherwise you have no way to 
know what your selection is going to return. You may be able to cheat 
your way through by creating a fake xml module and instantiate tyxml's 
functors on it to create all the combinators (that would be fun :p)

In any case, you will pay typesafety by a significant increase in 
verbosity and awkwardness. I'm not sure it's worth the effort, since a 
lot of real world html trees are not correct and that you never really 
need to select tyxml-constructed trees anyway. Simple compatibility with 
tyxml is much easier: you just have to agree with tyxml's signatures 
(which would deserve a bit of a cleanup).

[Xml_sigs.T]: 
https://github.com/ocsigen/tyxml/blob/master/lib/xml_sigs.mli#L21
[Xml_sigs.ITERABLE]: 
https://github.com/ocsigen/tyxml/blob/master/lib/xml_sigs.mli#L70
[Xml]: https://github.com/ocsigen/tyxml/blob/master/lib/xml.mli
[Tyxml_js]: 
https://github.com/ocsigen/js_of_ocaml/blob/master/lib/tyxml/tyxml_js.mli