Bug #5852: XML Transformer generates invalid XHTML - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #5852

closed

XML Transformer generates invalid XHTML

Added by Janne Wulf about 1 year ago. Updated about 1 year ago.

Status:

Closed

Priority:

Normal

Assignee:

Category:

Serialization

Sprint/Milestone:

Start date:

2023-01-24

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

11, 12, trunk

Fix Committed on Branch:

11, 12, trunk

Fixed in Maintenance Release:

11.5, 12.1

Platforms:

.NET, Java

Description

I am using Saxon-HE 11.4 to serialize a XHTML document. The document already defines the meta element :

<meta charset="utf-8"/>

Using the xml transformer, the MetaTagAdjuster now adds an additional meta element:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>

Having these two charset declarations in the XHTML document is illegal.

We can avoid inserting the content type at all with this setting:

transformer.setOutputProperty(SaxonOutputKeys.INCLUDE_CONTENT_TYPE, "no")

However, I think the MetaTagAdjuster should check if the charset is already defined.

Example: When having the following

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta charset="utf-8" />
    </head>
</html>

in a Document object and transforming it to written XHTML. It results in

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
        <meta charset="utf-8" />
    </head>
</html>

Actions

Copy link

Updated by Janne Wulf about 1 year ago

Actions

Copy link

Updated by Michael Kay about 1 year ago

Interesting. Doing this makes sense, but would not conform with the 3.1 serialization spec. The spec says that an existing meta element with http-equiv="Content-Type" is discarded, but not one with a charset attribute.

Perhaps the meta/@charset attribute wasn't in the HTML5 spec at the time the 3.1 serialization spec was published, in which case it would be sensible to support it in the way suggested. We'll look into it.

Actions

Copy link