Re: Is this legal XHTML 1.1?

Hello Ian,

Am Montag, 9. Dezember 2002 08:58 schrieb Ian Hickson:
> On Mon, 9 Dec 2002, Christian Wolfgang Hujer wrote:
> > And the note http://www.w3.org/TR/xhtml-media-types/ says XHTML 1.1
> > should not, but not must not, be sent as text/html.
>
> If you read RFC2119, you'll find that SHOULD NOT is equivalent to MUST
> NOT for most cases. I certainly can't see any amazingly important reason
most is not all...

> to use XHTML 1.1 over HTML 4.01 (or XHTML 1.0) in this case, ESPECIALLY
> if backwards compatability is important.
I do see. It is possible to write XHTML 1.1 which is at least backwards 
compatible enough to display properly in most major browsers.
Now what if the internal subset of the DTD declares attributes or elements 
that had associated semantics in HTML4.01 or XHTML 1.0, which do not have any 
function in XHTML 1.1, what should the user agent do then?

I think use HTML 4.01's semantics when the attribute or element is one of 
those included in XHTML Modularization, and use no (means plain XML) 
semantics when the attribute or element is not part of XHTML Modularization.
That's, of course, only concerning the XHTML namespace.
And HTML 4.01's semantics of course only means show the behaviour and 
rendering described there, syntax must be XHTML / XML.

> In any case that note is just that, a note. It is non-normative.
In any case there are far too many discrepancies between the IETF's RFCs and 
the W3C's Technical Reports concerning the WWW.

> > RFC 2854 is not valid in this case, anyway, it is outdated because it
> > does not know anything about XHTML 1.1 and is of no use here, I think.
> RFC 2854 is the _only_ specification allowing you to use text/html at all.
> It has the final word on the MIME type because it _is_ the MIME type.
Yes.
RFC 2854 tells me I may use text/html.
But it must not state anything about HTML itself, just refer to the W3C's TRs.
If it does, it's inappopriate and needs update.
But the problems are problems of today, not of the future.


> > RFC2854 says nothing about XHTML 1.1 or the internal subset of a DTD. (at
> > least I could not find anything about that in there)
> It refers (indirectly) to XHTML 1.0 section 3.1.1, of which items 1 and 5
> make an internal subset illegal.
No.
"The DTD subset must not be used to override any parameter entities in the 
DTD."
So an internal subset is allowed, but parameter entities may not be 
overridden.
In addition I could not find a reference on XHTML 1.0 Section 3 or 3.1.1, the 
only reference to that is referencing XHTML 1.0 at all.
Of course, the RFC does not know anything about XHTML 1.1 since the RFC is, as 
I said, outdated.
But an outdated RFC won't prevent us from discussing these topics.
And the RFC does not state anything about internal subsets, parameter entities 
etc..
I consider the RFC's reference to XHTML 1.0 to be of a more "XHTML in general 
meaning" than explicitely allowing XHTML 1.0 and disallowing all other 
versions.
Of course, the RFC leaves much room for interpretation on that.

So I can't see a reason why I should not use XHTML 1.1 with an internal subset 
overriding parameter entities and not serve it as text/html.

> > The point is that using internal subsets is basically allowed to extend
> > XHTML 1.1, otherwise it would have been explicitely forbidden as it is in
> > XHTML Basic. (That's my personal interpretation, of course)
>
> To extend it, yes. But extending XHTML 1.1 makes a document non-strictly-
> conformant XHTML 1.1.
Well, okay, then XHTML 1.1 + SVG + MathML is not strictly conforming XHTML 
1.1. I consider this is a serious problem: Again there's a gap between strict 
conformance and extensibility, even when using extensions described by the 
W3C. Ouch. This hurts.
But that's not the point, I might serve a non-strictly-conformant XHTML 1.1 
document.

> > If the document is served as text/html, it's tag soup anyway.
> Exactly. So using an XML variant is pretty pointless.
Well, there are ways to serve the document as application/xhtml+xml to those 
browsers that recognize that MIME Type, and to serve the document as 
text/html to others.

>    http://www.hixie.ch/advocacy/xhtml
Point 2 about script/style is outdated. No current non-XHTML ua renders 
script/style element contents, even when they are not commented.
Point 3 I am not sure of, I think the SGML specs had been updated for that.
Point 4 has bad argumentation: "Since most authors only check their documents 
using one or two UAs..., and thus most XHTML documents on the web now
   are invalid." Because plants are green, most trees are invalid. It's not 
concerning valid documents.
Point 5 again bad argumentation. Again it's not concerning valid documents.
Point 6 that could be considered by the CSS author.
Point 7 see 6
Point 8 Only sometimes. But definitely not on Windows when the ending is 
.html.
Point 9 No. I could use those tools to *parse* XHTML, not generate or modify. 
And XSLT won't transform *from* HTML, only *to* HTML, and only if the 
processor supports that.
Point 10 HTML 4.01 is not XML. That's reason enough.

Are you very sure about <br /> should be rendered as &#xA;>? Last time I 
looked that up in SGML, it looked otherwise to me.

Using XHTML and sending it as text/html is tag soup. But I might send it as 
application/xhtml+xml or text/html, depending on the UA.

I think you should update your document to reflect the fact that 
application/xhtml+xml exists.
Anyhow, both, RFC2854 and RFC3236 are informational:
4.2  Non-Standards Track Maturity Levels
4.2.2  Informational
(RFC 2026)
From 4.2.2:
An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation

So I can't see why you consider these two RFCs of such very high 
importantance.

> > I have the feeling, that Mozilla and IE6 interpret at least entities from
> > the internal subset of the DTD, even when the document is served as
> > text/html.
> Mozilla makes no attempt to parse the internal subset in HTML.
It does with application/xhtml+xml.

Bye.
-- 
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/

Received on Tuesday, 10 December 2002 01:43:21 UTC