This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In appendix A and B, the <xs:schema> lines are very long and don't display very well. The same applies to the IF spec, appendix A.
Inserting carriage returns in the schema files do not fix this. So there is something in the process of generating the final html that causes this issue.
The problem could be fixed by adding <pre> tags in the html file, but the line itself is generated as one long line. This takes place when the .xsd is generated by the xslt transform. I have not been able to figure out how to address this yet.
I've looked at this now, and the cause is simple: the version of the schema included in the HTML is generated by an XSLT stylesheet performing a near-identity transform on the document (and adding a comment near the top). Since the standard serializer in most XSLT implementations don't introduce newlines between attributes in a start-tag, the start-tags get output onto single lines. In the case of this particular start-tag, that makes the line too long. There are several possible fixes that come to mind. In increasing order of the amount of effort they require, and (unfortunately) also in increasing order of desirability (at least, as it appears to me), the ones that occur to me first include: 1 grin and bear it. For WG-internal copies, just live with it. For publications, change the HTML manually by introducing newlines at appropriate points. (Add an entry to the editors' publication checklist, so it doesn't get forgotten.) 2 find an XML parser which (like xmllint and rxp) produces as output a canonical form of its input, and which also takes parameters for introducing line wraps to keep lines from getting too long. (Unfortunately, as far as I can tell neither xmllint nor rxp currently accept such line-wrap parameters or options.) 3 replace the XSLT transformation of the schema with a simple copy; take the text added by the XSLT and introduce it into the source maintained by the editors. 4 modify the serialization module to understand about requests to wrap start-tags between attributes to keep the lines from getting too long. Or, more simply, write an XSLT stylesheet to function as a serializer, and make it accept appropriate parameters for line length and related behaviors. It would be interesting to write a serialization stylesheet of type 4 as a sort of XML pretty-printer, but I do not foresee having sufficient time to do so in the next few months. So my current recommendation to the editors is: 1 or 3. If you choose 3 and need help getting it to work, let me know.
Fixed by MSM.