A P is a P is a P

MURATA Makoto eb2m-mrt at asahi-net.or.jp
Wed Nov 30 00:45:47 CET 2011


Dear colleagues,

Before writing down a numbered document,  I would like to give a short
e-mail for sketching the battle around namespaces and schemas.

XHTML had three subsets: strict, transitional, and frame.  Should all
three subsets use the same namespace?  Or, should each subset
has its own namespace?

The first camp wanted to have three namespaces.  One motivation
is to use namespace names (i.e., URIs) as references to schemas.
Since each subset has its own schema, three references are needed.

The second camp wanted to have a single namespace.  The slogan of this
camp was "A P is a P is a P".  In other words, an application program
(such as HTML editors) handles P elements in these three subsets (and
also preceding HTML specifications) in a very similar manner.  Proliferation
of namespaces simply block code reuse.

I am sure I have missed some important points in this debate,
but I know that the second camp won.

More about this battle, see
http://www.xml.com/pub/a/1999/10/names/namespaces.html

If you have access to the W3C mailing list archive, search
for the phrase "A P is a P is a P".

In the context of schema maintenance, people often raise questions
about changing namespaces.  When the content model of an element is
extended (for example, for allowing <xi:include>), should the namespace
be changed?

I always say that the same namespace be used if some application
programs before this schema change can often successfully handle
documents containing the change.  A new namespace should be introduced
when nothing will continue to work.

To me, namespace subsumption in MCE is useless.  It works only when
namespaces are renamed although old applications can continue to
handle new namespaces.  (Note: In the case of 29500, we do have strict
namespaces and transitional namespaces.  This is to intentionally
crash old application programs rather than receving incorrect results
from ISO 8601 cell values.)

Cheers,Makoto


More information about the sc34wg4 mailing list