RE: Comments on "one vocabulary, two serializations"

(bcc TAG because this has a reading on the 'versioning' document
as far as MIME types as external version indicators.)


# The important part of the requirements here is that XHTML MUST NOT be  
# served as text/html.

Any string of bytes can be served as "text/html", and the HTML5 
specification makes it clear that a HTML5 processor is required 
to process it one way or another, and gives the guidelines for
how to handle it. 

The words "MUST", "MAY", "SHOULD" in specifications are not written on
stone tablets brought down from the burning bush -- they're indicators
of the intent that the statement

"conformant with specification X"

is intended to mean
     "Always does what specification X says MUST be done"
     "Does what specification X says SHOULD be done, unless there is a
        'good' reason not to"
     "Might do what specification X says MAY be done"
     "Does not do what specification X says MUST NOT do" 
    etc.

MIME types are used to label content. A MIME conformant receiver
treats content labeled with a MIME type according to the definition
of the MIME type supplied for it. 

> HTML5 does intend to be the one document that  
> registers text/html

presumably someone intends to update the RFC Dan and I prepared 
which currently registers text/html

> and will not allow XHTML to be served as text/html 

This part I don't get. It's fine to define text/html,
and give rules about how content labeled as text/html
should or shouldn't be treated.

If the document produced by this working group is intended
to be a definition of the Hypertext Markup Language, then
it defines that language; when it registers the MIME type,
it gives the rules for the use of the external indicator
("version indicator"). 

There also needs to be a single document defining
 application/xhtml+xml, of course, and it sounds like
the intent of W3C is that this committee maintain
that MIME registration also.

> -- although XHTML that happens to also be a valid HTML document  
> can be. As far as I can tell the requirement above doesn't really  
> affect the existing registrations of application/xml or application/ 
> xhtml+xml - they say what may be served with those MIME types, and  
> XHTML5 certainly qualifies.

> But perhaps a different fruitful way to think of this is to make it  
> definitional, rather than a matter of conformance requirement.

Yes, that was my point. 
> A resources served as text/html *is* (possibly invalid) HTML, 
> and *is  not* XHTML.

Exactly, at least "on the web". Perhaps the "architecture of the
web" document doesn't make the relationship between MIME types
and languages clear enough?

> The purpose of this language is to clarify that the difference between  
> HTML and XHTML, in the Web context, is determined by the MIME type,  

Well, the MIME type is used as an external indicator, in content,
as to which language is intended.

> and not by particular DTD declarations or certain uses of slashes, or  
> whatever other things people may mistakenly think makes a document  
> XHTML.

In lieu of an external indicator (if one isn't available), and
in some situations where mislabeling has been common, additional
heuristics are often applied, leading to content type sniffing,
and poor interoperability (because one language was intended
but the wrong one implied.)

Received on Sunday, 26 July 2009 04:55:08 UTC