Re: Testing parse-html

>   I don't think our scope extends to things that can only work on the
browser
Sorry the such impression took over. I am on the side of the "evolutionary
architecture" approach. Which means in this case to expose the delegation
of the DOM creation, parsing, etc. to the environment.  Of course with fall
back to complimentary default implementation.

I.e. there should be no conflict between browser vs own implementation.
Rather the synergy :)
-s

On Fri, Dec 23, 2022 at 11:32 AM Michael Kay <mike@saxonica.com> wrote:

> >
> > This would not be the case if the proposed function parse-html() had
> another overload that accepts an HTML DOM model (already created by the
> browser) and converts it into XDM - I think the possibility and usefulness
> of this has already been mentioned by Sasha a few times.
>
>
> This is obviously a useful feature to offer for a processor that runs in
> the browser, but I don't think our scope extends to things that can only
> work on the browser: that's always going to be processor-dependent.
>
> Michael Kay
> Saxonica
>
>
>
>