This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29345 - Failure to close empty elements makes use of XML-based tools for proofing overly difficult - Serialization
Summary: Failure to close empty elements makes use of XML-based tools for proofing ove...
Status: RESOLVED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Serialization 3.1 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-17 20:09 UTC by Patrick Durusau
Modified: 2015-12-18 03:35 UTC (History)
0 users

See Also:

Attachments

Description Patrick Durusau 2015-12-17 20:09:29 UTC 
From XSLT and XQuery Serialization

[FODC0002] "file:/home/patrick/working/w3c/XSLT-XQuery-Serialization3.1.html" (Line 75): The element type "link" must be terminated by the matching end-tag "</link>".

[FODC0002] "file:/home/patrick/working/w3c/XSLT-XQuery-Serialization3.1.html" (Line 75): The element type "meta" must be terminated by the matching end-tag "</meta>".

2 non-closed <meta> elements

[FODC0002] "file:/home/patrick/working/w3c/XSLT-XQuery-Serialization3.1.html" (Line 76): The element type "img" must be terminated by the matching end-tag "</img>".

1 non-closed <img> element

[FODC0002] "file:/home/patrick/working/w3c/XSLT-XQuery-Serialization3.1.html" (Line 86): The element type "br" must be terminated by the matching end-tag "</br>".

138 non-closed <br> elements

[FODC0002] "file:/home/patrick/working/w3c/XSLT-XQuery-Serialization3.1.html" (Line 809): The end-tag for element type "col" must end with a '>' delimiter.

4 non-closed <col> elements

[FODC0002] "file:/home/patrick/working/w3c/XSLT-XQuery-Serialization3.1.html" (Line 5099): The element type "hr" must be terminated by the matching end-tag "</hr>".

2 non-closed <hr> elements

I make that to be 148 edits that must be made to use XML based tools on the most recent XSLT and XPath Serialization 3.1 Candidate draft.

I realize this is a production error but it is one that significantly impacts the review of this draft.
Comment 1 C. M. Sperberg-McQueen 2015-12-17 20:34:25 UTC 
Thank you for the bug report.  Can you provide a little more information?  In particular, what software is raising these errors?

Both the document produced by the editorial production system and the production currently served from http://www.w3.org/TR/xslt-xquery-serialization-31/ look well-formed to me; I do not see any unclosed link, meta, or img elements.

More convincingly, perhaps, the document looks well formed to rxp and libxml, as the following fragment of my console log illustrates:

  [cmsmcq misc (0)]$ curl http://www.w3.org/TR/xslt-xquery-serialization-31/ > ser31.xhtml
    % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                   Dload  Upload   Total   Spent    Left  Speed
  100  306k  100  306k    0     0  64.7M      0 --:--:-- --:--:-- --:--:--  149M
  [cmsmcq misc (0)]$ rxp -s ser31.xhtml 
  [cmsmcq misc (0)]$ xmllint --noout ser31.xhtml 
  [cmsmcq misc (0)]$ tail +74 ser31.xhtml | head -3
                                            text-decoration: none }
  /**/
  </style><link rel="stylesheet" type="text/css" href="//www.w3.org/StyleSheets/TR/W3C-CR.css" /></head><body><div class="head">
  [cmsmcq misc (0)]$ 

The last bit shows the link element complained about in the first error message given.  It looks like a well-formed sole-tag to me; what software is not accepting it?

Could something in the path from http://www.w3.org/TR/xslt-xquery-serialization-31/ to your hard disk have transformed it from XHTML 1.0 Transitional into HTML that is not XHTML?
Comment 2 Patrick Durusau 2015-12-18 03:35:35 UTC 
I was using BaseX, which was correctly reporting errors with the file as I presented it.

However, the file as displayed (CNTR-U) in Chrome, is not the same file as saved by Chrome.

In particular, for some unknown (to me) reason, Chrome is stripping out the closing "/" from empty elements.

My bad. 

I have marked the status of this bug (and soon the others) as Resolved, Invalid. 

Please re-set if some other notation is more appropriate.

Hope you are having a great week!

Patrick