[Bug 14565] Chain of normative statements connecting MIME type to HTML vs. XHTML is broken or unobvious

http://www.w3.org/Bugs/Public/show_bug.cgi?id=14565

--- Comment #3 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-10-27 20:05:36 UTC ---
>  * A normative requirement that says which parser must be used for which input
> MIME types.

For text/html, this is now done (by fixing a bogus requirement that was
attempting to do this before). For XML, it's done in the context of navigation.
I don't think it's our place to do this for XML in other contexts.


>  * A normative terminology definition for an "XHTML document". (The spec talks
> about writing and parsing them suggesting that an "XHTML document" is at least
> a sequence of characters or bytes.)
>
>  * Better clarity that the terms "HTML document" and "XML document" are
> normatively defined by DOM4 / Web DOM Core.
> 
>  * Since "HTML document" and "XML document" are defined to be data structures
> in DOM4 but an "XML document" is defined as textual source in the XML spec,
> better clarity about terminology (possibly saying that the terms refer to both
> data structures and their serializations) and an explanation how one can
> "write" "HTML documents" if they are defined as data structures rather than
> serializations.

I've added a few paragraphs defining these, but it's not very satisfactory. The
problem is that we have multiple concepts and we all refer to all of them as
documents, and actually going through the specs to use different terms for each
one would at this point be quite time-consuming and error-prone. If there are
specific occurrences where the ambiguous terms cause real trouble, please let
me know.


>  * A normative statement requiring a serialization constructed by following the
> "writing HTML documents" section to be labeled as text/html and a requirement
> for a serialization constructed by following the "writing XHTML documents"
> section to be labeled as application/xhtml+xml.

I'm not sure what such a requirement would mean. For example, what would the
implications be on a polyglot document's labeling? Would it mean that you could
never label such a document that happened to match the HTML syntax as as
text/plain? Would it mean that you should not label non-conforming documents as
text/html, separate from their not being conforming in the first place?

Instead, the spec specifies (in the text/html definition) that the act of using
the text/html label declares that the resource is HTML. Is that sufficient?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 27 October 2011 20:05:38 UTC