HTML serialization: `html-version` and `version` parameters; allowed values

[ChristianGruen]

The serialization spec says (HTML Output Method: the version and html-version Parameters):

If the html-version serialization parameter is not absent, the requested HTML version is the value of the html-version serialization parameter; otherwise, it is the value of the version serialization parameter.

fn:serialize defines the following defaults:

• html-version: 5
• version: 1.0

I wonder whether these rules cover all possible cases:

1. Is it correct that HTML will be serialized as HTML5 if no options are supplied?

(: html-version=5 :) 
serialize(<html/>, { 'method': 'html' })

2. If only version is supplied, is it correct that it is ignored because of html-version defaulting to 5?

(: html-version=5 ? :) 
serialize(<html/>, { 'method': 'html', 'version': '4.01' })

3. If no, i.e., if { 'version': '4.01' } is expected to overwrite the default for html-version, how can we know at which stage the default values are to be considered?

In addition, the serialization specification mentions versions HTML 4.01 and HTML5 various times, but it seems to be up to the implementation to decide which HTML versions to support. However, we seem to have test cases for 4.0 and 5. Would it make sense to define a miminum set of versions that need to be supported?

Finally, for some reason, the html-version parameter was defined to be a decimal, whereas version is defined as a string (since XQFO 3.1). Maybe this leads to the surprising result that Saxon seems to accept the option { 'version': '4.0' }, but rejects { 'html-version': 4 }.

[ChristianGruen]

Our current approach:

• To interpret version and html-version equally, we normalize numeric html-version doubles (4, 4.01, 5) to strings (4.0, 4.01, 5.0)
• We serialize as HTML5…
  • if html-version is 5.0, or
  • if html-version is empty and version is 5.0, or
  • if both html-version and version are empty.

In other words, we don’t assume a default value for html-version, as it might conflict with a supplied version string.

[rhdunn]

I think it makes sense to require just "HTML 5 or later (including the WHATWG Living Standard)". HTML 5 can accept and parse the older versions of HTML (HTML 4.2, XHTML 1.0, etc.). I don't know how much the Living Standard has deviated from the HTML 5 specs, but they should be compatible, at least for parsing it and constructing an XML/XDM representation.

[ChristianGruen]

Sounds good (→ #1891)

[rhdunn]

Hmm. For serialization https://www.w3.org/TR/xslt-xquery-serialization-31/#html-output specifies version to be 4.0, so that should be supported for backward compatibility. We should also allow 5/5.0 to enable HTML5 serialization (flexible, as above).

The question then is should implementors be allowed to use HTML5 serialization when version 4.0 is specified. I'd probably say yes. -- Browsers have supported HTML5 for a long time. That said, I'm not sure what issues there would be aside from disallowing HTML5 specific elements/attributes (e.g. main and aside).