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

>> Implementations that support more than one language or incompatible 
>> version need to, along with the code that can generate or access a DOM, 
>> remember the language or version associated with the code.

> That would violate the spirit of our DOM Consistency design principle.

The spirit of principles need to be examined against the
realities of compatibility and practice.

> It would prevent reuse of scripts across multiple document types  For 
> example, it would mean there would have to be a multiple versions of the 
> dojo libraries, or the dojo library would have to detect which "mode" it 
> was in and then use the right code paths. 

>  Experience just with the "quirks mode" DOM API differences and 
> the few differences that specs required between HTML and XML modes
>  has shown overwhelmingly that such differences  have a huge cost 
> associated with them. This is how we ended up with the 
> DOM Consistency design principle for XML vs HTML; I would posit that the 
> same reasoning would apply to different XHTML versions.

The reality of practice seems to be that there are "versions", currently
switched on by DOCTYPE, for "quirk mode" or "standard mode" and
that some browsers switch between one version and another depending
on the DOCTYPE. 

The need for multiple libraries comes from having incompatible
languages or language versions. Incompatible languages and 
language versions should be avoided--- however, not providing
a way of detecting which of several incompatible languages
or language versions was intended is a head-in-the-sand way
of pretending like they don't exist, and makes the problem
worse, not better. The best way to reduce incompatibility
is to make things compatible, of course.  But it makes no
sense to say that because incompatible versions 
are bad, there should not be any way of designating or 
detecting which one you have.

>> I'm not sure there's a use case for a script embedded in one language or 
>> version to generate a document in another language or incompatible 
>> version.  Is there?

> Assuming we're still talking about XHTML1 and XHTML2 being implemented in 
> the same browser (are we? It's unclear to me exactly what the point of 
> this thread is at this point), then one use case might be an XHTML2 
> document embedding a gadget or advertising unit written for XHTML1.

We're talking about ISSUE 4.

XHTML1 and XHTML2 are just one example of two different HTML family
documents, among other pairs.

> Note that having XHTML2 and XHTML1 share a namespace would also mean that 
> there was no way even without scripting to embed content written for 
> XHTML1 and content written for XHTML2 into the same SVG document.

No, having a root element or attribute is another proposal that would
allow the different languages sharing the same namespace to appear
in the same document.

> Anyway, XHTML2 vs XHTML1 seems out of scope for this mailing list
> seems we should discuss this elsewhere, if at all.

The issue, ISSUE 4, is the about versioning mechanism for HTML5.
ISSUE 4 is in scope for this mailing list. 
http://www.w3.org/html/wg/tracker/issues/4 

I accepted ACTION-93, to make a proposal on doctype and versioning.
Discussing ACTION-93 is in scope for this mailing list.
http://www.w3.org/html/wg/tracker/actions/93

One of the considerations is that HTML5 should prefer to use the
same mechanism for versioning as other members of the HTML family.
The consideration of compatibility of version mechanisms is
in scope for this issue and thus for this mailing list.

The specific instance of versioning between XHTML1 and XHTML2
is an example of versioning for the HTML family, and so the
example is in scope for discussing the compatibility consideration
of the issue, which is in scope for this mailing list.

If the consensus of the working group, as judged by the 
chairs, is that the ISSUE 4 is actually out of scope,
or that ACTION 93 is out of scope, or that the considerations
I have given to the versioning mechanisms of HTML1 and
HTML2 are out of scope for consideration in ISSUE 4
or ACTION 93 are out of scope, then I will accept that.

As it stands, though, trying to declare a critique out
of scope seems like a poor excuse for avoiding serious
technical arguments in favor of an otherwise untenable
position.

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

Received on Wednesday, 18 February 2009 19:52:28 UTC