W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: Namespace

From: Robert Burns <rob@robburns.com>
Date: Mon, 16 Jul 2007 04:14:35 -0500
Message-Id: <EB26BBB1-050B-437A-9131-36946CE110F2@robburns.com>
To: HTML WG <public-html@w3.org>

H Lachlan,

On Jul 15, 2007, at 8:49 PM, Lachlan Hunt wrote:
>
> Robert Burns wrote:
>> On Jul 15, 2007, at 7:35 PM, Maciej Stachowiak wrote:
>>> Is there a draft of XHTML2 yet that uses the XHTML1 namespace? ...
>> My understanding was that the current namespace is used as a  
>> convenience or temporary namesapce placeholder. That is until the  
>> draft reaches a certain status, it is expected to use this  other  
>> temporary namespace. If I understand correctly this temporary  
>> namespace had nothing to do with the eventual aim of the WG. In  
>> other words it wasn't meant to be read s not using the original  
>> HTML namespace.
>
> It doesn't really matter if the XHTML2 WG attempt to reuse the  
> XHTML1 namespace, they will fail if they try.  As I, and others,  
> have explained previously, XHTML2 is fundamentally incompatible  
> with XHTML1 and simply cannot reuse its namespace without breaking  
> compatibility.

I believe that XHTML2 is trying to be compatible with the existing  
HTML namespace. HTML5 is also trying to remain compatible with the  
HTML namespace. Earlier I outlined my thoughts on what I think  
namespace compatibility entails:

<http://lists.w3.org/Archives/Public/public-html/2007Jul/0759.html>

There I listed five types I think could constitute name collisions  
(there may be others). My biggest concern are the first two types  
since I think those are most critical for maintaining the integrity  
of a namespace. Right now I think XHTML2 has collisions only in the  
last three items (though I may be forgetting some). On the other hand  
 though I'm sure we can fix this  our current draft has collisions  
of type 1 even.

1) meaning: and this relates not only to UA treatment, but also the
meaning ascribed by previous recommendations.
2) subtracting from the content model: i.e.,
	content model for elements
	making data type more restrictive for attributes
3)removing names from the namespace
4) adding to the content model: i.e.,
	content model for elements
	making data type less restrictive for attributes
5) adding names to the namespace

On the issue of XHTML2 incompatibility with XHTML1, some time ago you  
listed several issues with the current XHTML2 draft:

<http://lists.w3.org/Archives/Public/public-html/2007Jun/0700.html>

However, this message basically just lists outstanding issues in the  
XHTML2 draft. Not, as you suggest, insurmountable compatibility  
issues. Nor are they serious namespace collisions.

> If they do reuse the namespace, it will be impossible for a UA to  
> support both XHTML1 and XHTML2 at the same time, and so it is both  
> unnecessary and impossible for XHTML5 to be compatible with XHTML2  
> by design.

I don't think that's right. Without namespace collisions, its hard to  
imagine what would stop a UA from implementing both XHTML2 and  
XHTML1. Chaals also responded to say this has already largely been  
accomplished in Opera (with an XForms extensions).

<http://lists.w3.org/Archives/Public/public-html/2007Jun/0778.html>

I think there could be some namespace collisions in XHTML2 of types  
3, 4 or 5, but I think most of those would show up in the XForms part  
of the specification. In fact many of the document related (as  
opposed to forms) content model changes in XHTML2 are also in HTML5.  
This merely suggests that XForms may have trouble integrating with  
the HTML namespace. However, XForms has its own namespace and since  
XHTML supports XML compound documents that's not really much of an  
issue.

> Even if they don't reuse the namespace, XHTML2 is designed for a  
> completely different market from XHTML1/XHTML5, and (even though it  
> would be theoretically possible) it seems unlikely that both will  
> be implemented side by side anyway.

I really want to push this WG to plan for the future. However, I  
usually try to avoid predicting it. I really don't think any of us  
can say much definitive about what will happen with any of these  
recommendations.  We can only cross our fingers and hope for the best.

> So I'd like to remind everyone that XHTML2 is completely irrelevant  
> and unrelated to XHTML5 and that attempting to design for  
> compatibility between them is not a goal.

At the same time, we may be sharing the same namespace URI. So I  
don't think its helpful at all to not address issues that could cause  
problems for all of our constituencies: users, authors and UA  
developers alike. The use-case that triggered this discussion was  
over the issue of what should our recommendation say on UA  
conformance with regard to <img> elements that have content:  
something that is permitted as fallback in XHTML2.  The <img> element  
is not to have content in HTML5, however with an XML serialization  
such an error is clearly an invalidity condition and not an well- 
formedness violation (in text/html the distinction is unclear and  
depends on a UAs particular error parsing algorithm). Even if our  
author conformance criteria tells authors that they must keep <img>  
elements empty, that would not stop us from insisting that HTML5 UA  
must replace the entire <img> element with the sourced image (in  
either serialization; I believe this is already a conformance  
requirement). Additionally, including something like: "UAs should  
make the contents of an <img> element available as fallback along  
with other fallback content whenever the sourced image cannot be  or  
is not by user option  displayed." A few sentences like that could  
help maintain some  consistency across the namespace.

Perhaps someone from the W3C could speak to this issue, but are we to  
assume that "XHTML2 is completely irrelevant and unrelated to XHTML5  
and that attempting to design for compatibility between them is not a  
goal.", even though we may be sharing the same namespace?

Take care,
Rob
Received on Monday, 16 July 2007 09:14:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:47 UTC