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.