- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 21 Apr 2010 15:22:52 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: "Henry S. Thompson" <ht@inf.ed.ac.uk>, public-html@w3.org, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, "noah_mendelsohn@us.ibm.com" <noah_mendelsohn@us.ibm.com>, "www-tag@w3.org" <www-tag@w3.org>
On 20.04.2010 23:06, Ian Hickson wrote: > ... > Indeed, thanks, that's very helpful. > > Looking back at the proposal with this in mind: > > On Thu, 15 Apr 2010, Henry S. Thompson wrote: >> >> In section 12.1 [1] >> >> Add >> >> *Introduction and background* >> >> HTML has been in use in the World Wide Web information >> infrastructure since 1990, and specified in various informal >> documents. The text/html media type was first officially >> defined by the IETF HTML working group in 1995 in [HTML20]. >> >> Subsequent standardization work at the W3C relevant to this >> media type was published in [HTML32], [HTML40] and [HTML401]. >> >> This registration updates [RFC2854] by identifying this >> specification as the relevant specification, without ruling out >> continued use of the text/html media type for older documents. > > Adding an "introduction and background" entry in the registration template > seems to be at odds with RFC4288. Would it be acceptable to add material > that satisfies the rationale described above (such as the text proposed > above) to the Introduction and History sections of the spec? That seems > like it would be more consistent with how RFC2854 and other MIME > registrations are written, with the introductory text being in a separate > section than the MIME registration. Yes, this should be in a section that the template just references. >> and replace >> >> *Interoperability considerations:* >> Rules for processing both conforming and non-conforming >> content are defined in this specification. >> >> with >> >> *Interoperability considerations:* >> >> This specification defines rules for processing not only >> conforming also non-conforming documents, including those >> which conform to the early specifications listed above. > > It also has rules (the same rules) for processing documents that try but > fail to conform to earlier specifications -- the rules cover any arbitrary > bit stream. However, the rules don't cover how to handle features that > have never been (widely) supported, for example it doesn't say how to > handle<HP1> from Tim's earliest drafts, nor does it say how to handle > obscure SGMLisms allowed in HTML4. Therefore I'm not sure the suggested > text above is completely accurate. > > Would it be acceptable to merely add a sentence such as the following?: > > These rules also define how to process legacy documents written for > earlier versions of HTML. > > This would avoid implying that any document created today that complies to > the old specs would work, but does mention that the rules are intended to > be compatible with how the old specs were used. If we're serious about that we'll have to fix issues in the spec with respect to the treatment of HTML4isms (the instructions for the treatment of @profile come to mind immediately, but there is probably more). >> [and replace] >> >> *Published specification:* >> This document is the relevant specification. Labeling a >> resource with the text/html type asserts that the resource is >> an HTML document using the HTML syntax. >> >> [with] >> >> *Published specification:* >> >> This document is the relevant specification. Labeling a >> document with the text/html type asserts that the document is >> a member of the HTML family, as defined by this specification >> or those listed above [ref Introduction and background], and >> licenses its interpretation according to this specification. > > I hesitate to use this exact text because the term "HTML family" is rather > unclear. It also removes the mention of the carefully-defined term "HTML > document", which I think is important. > > Would the following be an acceptable compromise?: > > This document is the relevant specification. Labeling a > resource with the text/html type asserts that the resource is > to be interpreted as an HTML document using the HTML syntax, and > that it conforms either to this specification or to an earlier > HTML specification. As Leif, I think that "HTML family" is much clearer as the "definition" of HTML document you mentioned. Finally, we'll have to make similar changes to the application/xhtml+xml registration, right? Best regards, Julian
Received on Wednesday, 21 April 2010 13:23:32 UTC