Re: Namespace

On Jul 16, 2007, at 11:01 PM, Lachlan Hunt wrote:

>
> Robert Burns wrote:
>> On Jul 15, 2007, at 8:49 PM, Lachlan Hunt wrote:
>>> 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.
>
> That's what some in the XHTML2 WG believe also, but belief in  
> something does not make it true.
>
>> 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.
>
> Try reading that a little more carefully.

I did.It doesn't say what you think it says.

> I listed both incompatibilities and outstanding issues, none of  
> which the XHTML2 WG seem particularly interested in addressing.   
> Specifically, some of the incompatibilities listed include:
>
> * <label>
> * <input>
> * <object src=""> vs. <object data="">
> * Renaming <script> to <handler>
> * etc...

I did read carefully. I've also read the XHTML2 draft and most  
everything you listed in your post are listed as outstanding issues  
in the XHTML2 draft. As for this list above, these cannot possibly be  
namespace issues. The issues with <input> and <label> relate to the  
type 4 namespace collision (a minor issue for namespace  
compatibility.. The other two there are not namespace collisions at  
all. You have it backwards. There is no namespace collision  
whatsoever if we add a name to the repertoire (like adding @src to  
<data>) or adding <handler>. Those are not namespace collisions at  
all. Whatever compatibility problems they introduce, they have  
nothing to with namespace problems whatsoever.

>>> 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.
>
> I think you misread what I wrote.  Sure, if they used a different  
> namespace, there would be no collision and could theoretically be  
> implemented together.  But I said "if they do reuse the namespace",  
> where there would be collisions, it will be impossible.

Even if they use the XHTML1 namespace (and I think we should assume  
they will), there are no serious namespace collisions (only those of  
type 3 - 5). Whereas our current draft has serious namespace  
collisions. Obviously both projects are in draft phase, so anything  
can change. However, we should have some liaison with the XHTML2  
group to make sure we're on the same page regarding namespace.  
Nothing in our charter says we have the right to use the XHTML1, let  
alone run roughshod over it. For example adding the line I suggested  
for UA conformance on <img>. in the xml serialization is a minor  
alteration of our recommendation that will prevent many difficulties  
down the line. There is little reason (none that I can see nor are  
you offering any) to not try to be compatible with other W3C  
recommendations (and to be mindful of such developments as we move  
forward).

>> 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>
>
> That only works in Opera because XHTML2 currently uses a different  
> namespace, and some things in XHTML2 can be implemented using  
> generic XML processing with CSS.  AFAIK, there has been no work on  
> implementing XHTML2 in any released version of Opera.  It has just  
> as much support as the hypothetical FooML would, if it were defined.

I'm surprise Chaals didn't mention the use of a different namespace.  
Regardless, there is no indication that there are any name collisions  
in XHTML2 with XHTML1 that could lead to any problems if XHTML did  
not use a different namespace. Even with XForms, where there is a  
type 4 collision[1]., that is merely a reversal of the  content  
models of <input><label /></input>. Its hard to imagine how that  
would constitute an insurmountable name collision. If anything the  
use of that content model would act as a signal to a UA that this was  
an XForms <input> and not a legacy HTML <input>. Such signals like  
that would provide all the information a UA needed to process these  
differently behaving elements in the same namespace.

>> 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.
>
> As I said, XHTML2 *cannot* realistically reuse the the XHTML1  
> namespace because it is fundamentally incompatible.
>
>> 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.
>
> If the XHTML2 WG want to reuse the XHTML1 namespace, then they will  
> have to deal with all the problems themselves.  We should not have  
> to deal with the problems they create.

This is not about problems with namespace issues. This is  about two  
different recommendations that are being drafted simultaneously that  
both want to use the same namespace. If each of us behaves properly  
with respect to namespaces, than there will be no problem. The only  
problem is if we both come u with an element or attribute that has  
the exact same name but completely different semantics.

However, sharing the same namespace creates other issues that we  
should be mindful of. That relates to things like the <img> element  
with contents. There are such little steps we can take that will save  
everyone a lot of trouble that I can't imagine why we wouldn't take  
them (I'm talking again about a UA conformance requirement that says  
"UA should/must expose the contents of an <img> elment as fallback").

>> 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.
>
> We can discuss the advantages and disadvantages of that proposal  
> and make a decision based on its own merits, but consistency with  
> XHTML2 is not a valid reason.
>
>> 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?
>
> Yes, because it is not our responsibility to deal with the problems  
> created by the XHTML2 WG.  While I agree that it would be  
> unfortunate if they shared the same namespace, it will not create  
> any major practical problem in reality until some vendor attempts  
> to support both XHTML2 and XHTML5 in the same implementation.  That  
> seems unlikely and the market will ultimately decide upon the  
> relevance of XHTML2.

My goal with my product is to support both HTML5 and XHTML2. If they  
share the same namespace, I hope to do so in the same document. So I  
think the possibility that others may want to mix these vocabularies  
is pretty high. Take a look at the discussions over versioning and  
you'll see there's  a strong sentiment against having bifurcated  
implementations: in other words an implementation that  tries to  
recognize the version used within a namespace and then forks behavior  
based on that.

Take care,
Rob

Received on Tuesday, 17 July 2007 04:43:42 UTC