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

Hi Robin,

On Feb 18, 2009, at 7:42 AM, Robin Berjon wrote:

> On Feb 17, 2009, at 20:12 , Robert J Burns wrote:
>> On Feb 17, 2009, at 3:31 AM, Ian Hickson wrote:
>>> On Tue, 17 Feb 2009, Robert J Burns wrote:
>>>> On Feb 16, 2009, at 9:35 PM, Ian Hickson wrote:
>>>>>
>>>>> Given the following function in a script:
>>>>>
>>>>> function test(imp) {
>>>>> // imp is a DOMImplementation object
>>>>> var doc = imp.createDocument(null, null, null);
>>>>> var e = doc.createElementNS('http://www.w3.org/1999/xhtml',  
>>>>> 'img');
>>>>> return e;
>>>>> }
>>>>>
>>>>> ...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.
>>>>
>>>> But that element has neither value set. I'm not following your  
>>>> example.
>>>
>>> The element has to be an element that acts as above for any  
>>> subsequent
>>> value set, changed, or removed for those attributes.
>>
>> So the script is a total distraction. You're simply saying that an  
>> 'img' element has to behave in a way that conforms to the  
>> implementation conformance criteria of HTML5. OK, fine we all knew  
>> that. For XHTML2 it would have to behave in a way conformant to the  
>> XHTML2 implementation criteria.
>
> That's not what was said. The point here is that HTML5 has a  
> requirement that code such as the above, which works today in HTML4  
> and XHTML1, keeps working as is and producing the same result. Since  
> there is no way above to tell whether the img element is an XHTML1  
> or XHTML2 object if XHTML2 takes over the namespace, there is no way  
> in which a browser could guess which behaviour to use.
>
> If you don't understand this from the short and abstract example  
> above, consider a more concrete if longer one:

I understand from the short example. And I also understand the longer  
example you provide. The scripting is simply a distraction. If the  
author is authoring to HTML5 then the author would not append child  
elements to the img element. So now you're producing invalid HTML5. If  
the author is producing XHTML2, then the author would not provide an  
alt attribute.  So you're also producing invalid XHTML2.

So for an author providing both an alt attribute and child elements  
and an implementation that tries to be both an HTML5 UA and an XHTML2  
UA, that UA would have to decide on its own error handling of this  
situation.  Note that this particular example is also due to Ian  
ignoring my earlier advice that HTML5 should provide error handling  
for this specific case[1] (I would give the same advice to the XHTML2  
WG if I served on that WG).

However, its fair to imagine that there are other situations than  
simply this one and other situations that may not be anticipated.   
This means that either HTML5, XHTML2, another specification or the  
implementation itself would need to negotiate these issues and specify  
error handling. However, the context provides all the information  
necessary to know how to process the document in the situation of a  
fully conforming document. In the case of an errant document, then the  
implementation has to decide on the error handling. However, that is  
due to incomplete error handling from HTML5 due to not heeding my  
earlier warnings about this.

> <svg xmlns='http://www.w3.org/2000/svg' width='320px' height='480px'  
> viewport='0 0 320 480' onload='test()'>
>  <script>
>    function test () {
>        var img = document.createElementNS('http://www.w3.org/1999/xhtml' 
> , 'img');
>        img.setAttributeNS(null, 'alt', 'Dahut Numero Uno');
>        img.textContent = 'Alternative Dahut';
>        document.getElementById('fo').appendChild(img);
>    }
>  </script>
>  <foreignObject id='fo'/>
> </svg>
>
> Today that shows "Dahut Numero Uno". If the UA suddenly supports  
> XHTML2 instead of XHTML1, then it'll display "Alternative Dahut"  
> instead. All of a sudden, my content is broken. If the application  
> supports both, it has no way of guessing (and the only safe strategy  
> for an implementer here is to default to XHTML1).

Certainly the UA can determine which type of document it is for  
conforming documents. For this non-conforming document the UA has to  
determine the error handling itself (because HTML5 decided not to  
specify error-handling in this situation).

> Because of this, if XHTML2 wishes to use same namespace as XHTML1  
> then is MUST be 100% compatible and not cause content to break. If  
> it really intends to be a rethink of XHTML that starts off from a  
> new, purportedly saner base, then it really MUST use a new namespace  
> lest it break content (and incur both wrath and abandon).

No, this is not a conflict between XHTML2 and XHTML1. It is a lack of  
error-handling specified in XHTML2 (if we leave HTML5 aside for the  
moment and cast stones at XHTML2 instead).

> You'll note that this has nothing to do with HTML5.

Only because we have set HTML5 aside for the purposes of casting  
stones at XHTML2.

> Reusing the same namespace for incompatible content is a really,  
> really terrible idea irrespective of whether HTML5 exists, or is  
> being worked on, or uses that same namespace.

I've been asking for someone to demonstrate an example of incompatible  
content and this is not one(we're looking for genuine name collision  
where context is insufficient to determine semantics). i've yet to see  
an example. I too have been looking into the issue myself and I  
haven't been able to come up with one.

> The reason HTML5 gets to use the namespace is because its absolutely  
> core design orientation is that it will be backwards compatible, no  
> matter how distasteful some corners of the specification need be.

These claims are repeated again and again, but as far as I can tell  
XHTML2 is more backwards compatible than HTML5 (due to the case of the  
redefined presentationally related elements I've mentioned before).  
Obviously I'm only speaking in terms of vocabulary here, XHTML2 is not  
backwards compatible in the sense that it can be used with a text/html  
parser.

> Furthermore, if the XHTML2 WG has had a change of heart and wishes  
> to be backwards compatible, then it needs to rethink its charter,  
> and rather than duplicate the work that was chartered to be done  
> here, either merge into this group, or focus on specifying how  
> XForms, XML Events, etc. can integrate into an (X)HTML5 based  
> framework (thereby inheriting work on making BC possible).

I think that would be unwise, since HTML5 is much more suited as a  
Browser Interoperability and Behavioral Specification than as an HTML  
vocabulary specification. The changes to the HTML vocabulary in the  
current HTML5 draft are really not appropriate for HTML authoring.

> To put it in a nutshell:
>
>  - if XHTML2 uses the same namespace
>    then it needs to be backwards compatible to not break content
>
>  - if XHTML2 is backwards compatible
>    it is duplicating the work being done here, and another  
> arrangement or merger should happen
>
>  - if, on the other hand, XHTML2 is starting from scratch and not BC
>    then it has no reason whatsoever to use the same namespace, and  
> good reasons not to

It is not at all clear what you mean by backwards compatible here.  
I've been asking for examples of backwards incompatibility and have  
yet to see one.  Certainly the example you've given represents a lack  
of clearly specified error handling in XHTML2. However, since HTML5  
also fails to provide error handling in this case (despite my repeated  
pleas to do so), I don't see how we can hold this against the XHTML2 WG.

Take care,
Rob

[1]: <http://lists.w3.org/Archives/Public/public-html/2007Jul/0752.html>