RE: ISSUE-4: Versioning, namespace URIs and MIME types

If there were multiple languages which used the same namespace,
(or multiple versions, HTML 5 and HTML 6 or whatever)
then imp.createDocument needs to choose which language
it is creating a document *in*, no matter how that version
is indicated in the serialization.

I imagine the simplest implementation would be that
imp.createDocument creates a document in the same language
or version in which the script was embedded.

That would make sense even without the XML serialization.
So a script in a HTML2 document would create a HTML2
dom, and a script in an HTML5 document would create 
a HTML5 dom. This should be the case even if the script
doesn't explicitly insert the namespace, version 
indicator, doctype, or have an explicit MIME type.

> ...browsers are required, for compatibility with legacy content, XHTML1, 
> DOM2 HTML, and DOM2 Core, to return an element that, when inserted into a 
> document, displays either an image as indicated by its "src" attribute, or 
> text as indicated by its "alt" attribute.

Legacy compatibility is one among several design goals which
are often traded off in the design process. The existence of
legacy table@summary attributes seems to have little weight
in the discussion, so the fact that there might be scripts
which would execute differently in HTML1 vs. XHTML2 or XHTML5
would need to be evaluated using only the same criteria.

> This is the case regardless of HTML5 or XHTML5 -- this has absolutely 
> nothing to do with this working group, it is based purely on specs that 
> were created in the late 90s, around a decade ago, years before HTML5 
> started. This is the world in which we find ourselves, writing HTML5.

In http://lists.w3.org/Archives/Public/public-html/2008Aug/0765.html
you said "HTML5 started from a clean slate".

So what previous specifications say has not, apparently, been
previously upheld as an inviolate design principle. What is
the consistent principle actually being applied here?

> A spec that changes the requirements around this script in a way that is 
> incompatible with existing browsers, content, and specs is going to have a 
> great deal of trouble getting implemented by Web browsers. Thus, we really 
> have very little room to manoeuver here -- HTML5 is constrained here, like 
> in so many other places.

Frankly, I would think scripting compatibility is most likely
the least feasible of all of the kinds of compatibility that
are desirable, and that the cases which would actually differ between
XHTML2 and XHTML5 are as rare as ones that would differ about
the differences between XHTML1 and XHTML5. In fact, a new
namespace for XHTML2 would likely have even more impact,
in terms of things that would needlessly break.

> XHTML claims 
> (section 1.1.2) that "strict element-wise backwards compatibility is no 
> longer necessary", and thus it exempts itself from the aforementioned 
> constraints. 

Considering "clean slate" quote above, whether the document itself
states its compatibility requirements or it is merely a mailing list
posting by the editor doesn't seem to me to be significant: compatibility
needs to be judged on actual impact on existing implementations, no?

> In conclusion: XHTML5 does not have a new conflict with XHTML2 even if 
> both use the same namespace. The conflict, insofar as there is one that 
> matters, already exists between XHTML1 and XHTML2, and exists irrespective 
> of XHTML5. I believe this issue to therefore be out of scope for the HTML5 
> specification, and do not propose to do anything about it (except for 
> changing the "relationship to XHTML2" section if they do indeed publish a 
> version of XHTML2 that reuses the same namespace).

There was a request to review the versioning and namespace issues,
and I volunteered to do that. I would suggest that this issue won't
go away until we document the arguments more carefully than has
been done in the past. At a minimum, the "relationship to XHTML2"
section will require working group review and consensus, and so
is legitimately a working group issue, and thus not out of scope.

> I would like to recommend that future discussion on the subject of 
> versioning focus on versioning in the face of DOM Core implementations and 
> the script given above, as that will help prevent discussion that could 
> not solve the problem (e.g. anything to do with DOCTYPEs, version="" 
> attributes, or MIME types, none of which are present in the above snippet, 
> despite that snippet creating an XHTML1/5 element). 

Script compatibility is certainly another requirement, and I didn't
see it among those raised in the many emails and wiki pages I reviewed
prior to posting about the topic (as requested.)

However, I do think versioning in scripting makes the most sense
under the assumption that scripts create elements in the same
version as the document in which the script is embedded.

I confess that I don't understand how scripting works in multi-format
compound XML objects, since the operation of HTML scripting and
SVG scripting and SMIL scripting etc. seem to be defined as if
the scope of "document" was the entire document and not one sublanguage
or another. Do Atom feeds allow scripting within the HTML which
is embedded, or is the issue of versioning within DOM scripting
only a single-language-document issue?

> I would also like to 
> recommend that any discussion for new features continue to consider the 
> need for graceful degradation, which requires us to continue to use the 
> same namespaces and tag names as is supported by legacy browsers, at the 
> very least for existing features, and ideally wherever possible.

I agree that "graceful degradation" is  a high priority among
the many sometimes conflicting design goals, and that reckless
use of different namespaces would hamper accomplishing that
goal. I don't think I would go so far as saying that "graceful
degradation" was absolutely a higher priority than every other
design goal, or that continued use of the same namespaces and
tag names was an absolute requirement of that highest priority
goal, or that every bit of W3C work should have the same 
compatibility goals as HTML5.

Regards,

Larry
-- 
http://larry.masinter.net

Received on Tuesday, 17 February 2009 19:32:56 UTC