This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When a document declared as DOCTYPE XHTML 1.0 (strict) does not declare an xmlns attribute on the html element, the validator currently (not before 0.8 apparently) gives an error message like this : ~~~~ Line 2, Column 1: Missing xmlns attribute for element html. The value should be: http://www.w3.org/1999/xhtml. <html xml:lang="en"> Many Document Types based on XML need a mandatory xmlns="" on the root element. For example, the root element for XHTML will look like: <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> ~~~~ This appears to be a bug, for the following reason: The DTD for XHTML 1.0 strict (http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd) contains this definition: ~~~~ <!ATTLIST html %i18n; xmlns %URI; #FIXED 'http://www.w3.org/1999/xhtml' > ~~~~ Note that is says FIXED, not REQUIRED. While it may well be true that "Many Document Types based on XML need a mandatory xmlns="" on the root element." as stated with the error message, that is not the case with XHTML 1.0 strict (or transitional or frameset), all of which declare a FIXED value of 'http://www.w3.org/1999/xhtml'. FIXED means it can have only the defined value, and that value is /already/ fixed; thus is it does not need to be declared (as it would if it were defined as REQUIRED); and if it /is/ declared (allowed), then it cannot have any other value. (see also my comment #10 on issue 68 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=68#c10)) I am basing this interpretation of FIXED (vs. REQUIRED) on several discussions with W3C people, notably a lengthy discussion with Al Gilman during an FPWG meeting in Amsterdam (in May 2001) on XML accessibility where I (as then member of the ATAG) was invited to be present. On the strength mainly of this discussion, and in my role (then) as Product Manager for Allaire HomeSite, I even deliberately created the "Tag Editor" for the html element in such a way that while it /displays/ the xmlns value while editing, it does *not* add this as an attribute to the html tag written out by the tag editor. I find it therefore quite curious, and disappointing, that suddenly (since v. 0.8) now the validator will state that documents that do not declare the FIXED xmlns value as an attribute are in error. It is of course possible that several W3C people's interpretation of FIXED vs. REQUIRED were in error. If this is the case, please refer to a document that clearly states that an attribute defined as having a FIXED value in a DTD *must* be declared in a document that conforms to that DTD. In other words, a document /preceding/ the XHTML 1.0 DTDs, defining the exact meaning of FIXED vs. REQUIRED. (In yet other words: what, exactly, causes the developers of the validator to think that FIXED means 'mandatory'?) Until I see such a document (I have never been able to track down anything), I will continue to believe that all XHTML 1.0 documents that do not declare an xmlns attribute on the html (root) element (which will include nearly all XHTML documents created with HomeSite 4.5 and 5.x) are, in fact, quite valid, and the error message issued by the validator is a bug.
In XHTML the namespace *has* to be declared, regardless of what the DTD states. See the conformance statement in the spec: http://www.w3.org/TR/xhtml1/#strict *** This bug has been marked as a duplicate of bug 68 ***
(In reply to comment #1) > In XHTML the namespace *has* to be declared, regardless of what the DTD states. > See the conformance statement in the spec: > http://www.w3.org/TR/xhtml1/#strict > > *** This bug has been marked as a duplicate of bug 68 *** > Thanks for that pointer. (Though I don't understand how an XHTML standard can be in conflict with its own DTD...) But this issue clearly is NOT a duplicate of #68! I'll mark this as closed instead.
> But this issue clearly is NOT a duplicate of #68! I'll mark this as closed > instead. That doesn't seem to work - I'll try reopening it first...
(In reply to comment #3) > > But this issue clearly is NOT a duplicate of #68! I'll mark this as closed > > instead. > > That doesn't seem to work - I'll try reopening it first... > OK, NOW I can close it, erasing the "duplicate" status. (I hate Bugzilla...)