W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: What's the problem? "Reuse of 1998 XHTML namespace is potentially misleading/wrong"

From: Robert J Burns <rob@robburns.com>
Date: Wed, 11 Feb 2009 14:47:26 -0600
Cc: "L. David Baron" <dbaron@dbaron.org>, HTML WG <public-html@w3.org>, plh@w3.org
Message-Id: <AB75A3B6-B118-4957-AA8C-4014305C784F@robburns.com>
To: Jonas Sicking <jonas@sicking.cc>, Lachlan Hunt <lachlan.hunt@lachy.id.au>

HI Jonas and Lachlan,

On Feb 11, 2009, at 1:37 PM, Jonas Sicking wrote:

> On Wed, Feb 11, 2009 at 11:23 AM, L. David Baron <dbaron@dbaron.org>  
> wrote:
>> On Wednesday 2009-02-11 10:10 -0800, Larry Masinter wrote:
>>> Generally namespaces name vocabularies and not languages that use
>>> those vocabularies; generally, versioning of languages is handled
>>> independently through some other mechanism (e.g., DOCTYPE as per
>>> ISSUE-4, which we will discuss soon although I've put it off), and
>>> generally, reuse of a namespace in a new version of a language is
>>> perfectly appropriate.
>> I would go further than merely saying reuse of a namespace is
>> appropriate.  I would say that using a new namespace for the same
>> vocabulary is *inappropriate*, for reasons I described in
>> http://lists.w3.org/Archives/Public/www-tag/2005Feb/0018.html
>> (So I support your proposal to close the issue.)
> Agreed on both accounts.
> However there is definitely an issue to solve, and that is how to
> solve the fact that both the HTML WG and the XHTML2 WG are defining
> next versions of XHTML1.1. And doing so in incompatible ways (i.e.
> neither spec is a strict superset of the other).

I do not think it is important for either spec to be a superset of the  
other to share the namesapce. However, the important thing is to  
coordinate to avoid name collisions in sharing the namespace.

However, HTML5 has introduced namespace collisions all on its own so  
that things like the 'small' element mean two different things within  
the same namespace. In other words a name collision where two separate  
elements share the same name. This is the type of thing a namespace  
should be avoiding or it ceases to have any meaning.

On Feb 11, 2009, at 1:36 PM, Lachlan Hunt wrote:
> But XHTML2 also has several major incompatibilities with XHTML1,  
> which would effectively make it impossible to implement both XHTML  
> 1.x and 2 in the same implementation, if they share the same  
> namespace [3].  XHTML 5, on the other hand, has not only been  
> designed with compatibility in mind, success is dependent upon  
> continuing to use the same namespace.

You've made these claims before and have not been able to support  
them. Can you provide some specific examples of name collisions in the  
draft XHTML2 with XHTML1 names?

In any event it is important to understand that names can be added to  
a namespace without any problem. Names can even be added by two  
separate workgroups as long as the semantic definitions of those names  
are coordinated between the workgroups.

However, changing the meaning of names is a tricker task. Julian's  
example of the 'rel' attribute taking on new meanings when used along  
side 'property' and 'content' attributes is not really a name  
collision issue since it is easy to identify the new context. On the  
other hand changing the meaning of 'small' to something entirely  
different is a namespace problem since it introduces a name collision  
where no one can decipher which meaning of 'small' an author intends.

Removing names is also not really a problem, though some coordination  
of workgroups may be needed as well. In other words we can deprecate  
the 'axis' attribute on the table element or the 'big' element without  
any concern. So in summary, the two main problems with namespace  
sharing are:

1) changing the meaning or semantics ascribed to names (this needs  
especially to be handled within each workgroup)
2) adding new names must be coordinated across workgroups to avoid  

Take care,
Received on Wednesday, 11 February 2009 20:48:05 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:42 UTC