We could add an options parameter to the XSLT document function, providing the same options as fn:doc. It's complicated by the fact that fn:document already has an optional second argument (a node whose base URI is to be used for resolving relative URIs) -- but we could solve that as we have done with deep-equal, by incorporating the base-uri-node into a new options parameter and making the second argument have a type of (node()|map(*)).
Or we could leave the functionality of fn:document alone, treating it as legacy, but add to the rules to define its effect in terms of the doc() function. We could mandate the values of fn:doc() options such as DTD-validation, schema-validation, space stripping, etc, or we could leave these implementation-defined.
Currently XSLT §4.3 says that documents loaded using doc(), document(), or collection() are subject to preprocessing: stripping of whitespace and type annotations as controlled by declarations in the stylesheet. It's a bit weird that XSLT should interfere with the semantics of doc() and collection() in this way, and now that doc() (and in future collection()?) have options parameters to control some of these behaviours, it's not clear how they are supposed to interact. One approach would be to say that if doc() or collection() has an options parameter, this overrides any default processing defined in §4.3.
We could add an options parameter to the XSLT document function, providing the same options as fn:doc. It's complicated by the fact that fn:document already has an optional second argument (a node whose base URI is to be used for resolving relative URIs) -- but we could solve that as we have done with deep-equal, by incorporating the base-uri-node into a new options parameter and making the second argument have a type of
(node()|map(*)).Or we could leave the functionality of fn:document alone, treating it as legacy, but add to the rules to define its effect in terms of the doc() function. We could mandate the values of fn:doc() options such as DTD-validation, schema-validation, space stripping, etc, or we could leave these implementation-defined.
Currently XSLT §4.3 says that documents loaded using doc(), document(), or collection() are subject to preprocessing: stripping of whitespace and type annotations as controlled by declarations in the stylesheet. It's a bit weird that XSLT should interfere with the semantics of doc() and collection() in this way, and now that doc() (and in future collection()?) have options parameters to control some of these behaviours, it's not clear how they are supposed to interact. One approach would be to say that if doc() or collection() has an options parameter, this overrides any default processing defined in §4.3.