W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > June 1997

Change of approach on the namespace problem

From: Tim Bray <tbray@textuality.com>
Date: Sun, 22 Jun 1997 23:53:30 -0700
Message-Id: <>
To: w3c-sgml-wg@w3.org
Summary: there are all sorts of good reasons for not rushing into 
fundamental namespace machinery re-engineering in XML/SGML at this time.  
In order to make experimentation possible within the bounds of legal XML, 
let's add ':' (or '::' or something else if there's a good reason) to 
NAMECHAR, with the provision that it is not for use in ordinary element 
types, and leave it at that for now.

Long version:

Having plowed back through the dialogue on the namespace question, it seems
that a change of approach is in order.  The mandate of this activity, as per 
our official billboard at w3.org, is to produce a version of SGML that
is appropriate for the Web.  In the areas of base language and hyperlinking,
we're doing fairly well, I think, in pursuit of that goal.

I do not find, in our charter, anything that mandates us either to

 (a) enhance ISO SGML to add namespace mechanisms, or
 (b) design technology to meet perceived needs in the Web community 
     for linking schemata to parts of structured documents.

It has become clear that there is not substantial consensus as to how
item (a) can best be achieved.  This should not be surprising; SGML
is a large and carefully-designed standard, and the issue of naming
objects is well-known to be one of the canonical hard problems in
computer science.   Upon reflection, it is clear that this is a job
for the 8879 revision.

It has become clear that there is no consensus here that item (b) has 
urgency as a priority, or that the people in Web community who feel a
strong need for this should be taken seriously, either in their statement 
of the requirement's existence, or in their ideas for how it might be 

Speaking on behalf of the people in W3C and certain vendor organizations
with whom I have been working, it is objectively the case that there is a 
*perception* of urgent need to have some machinery in this area, and a 
willingness to devote senior engineering resources to exploring workable 
designs for Web-oriented namespace/schema processing.  There is also, I am 
happy to report, a strong desire to stay within the bounds of legal XML as 
it stands today.

In order to allow progress to occur, I am hereby formally asking the
ERB to modify the next release of XML-lang by a syntactic addition
to NAMECHAR, so that should we choose to explore segmented-GI 
techniques for this purpose, we can do so within the bounds of legal
XML.  A good candidate would be ':', but the character is not a big
issue.  This addition should be accompanied by normative rules saying
the the new character(s) are reserved and should not be used in ordinary
element types.  Speaking only for myself, beyond this single change
I see little useful potential for additions to XML-lang 1.0 in
support of this class of problems.

I think this would meet the needs of all the parties in a good way.
The Web community can experiment with schema/naming issues on the world's 
biggest and most demanding testbed, and the lessons, good or bad, might
serve as input to the SGML revision's work in this area.  On the other 
hand, it is clear that such an effort would not claim either direction 
over or support from the SGML revision process.  (Given the motivation, 
this work is going to be highly biased toward the special needs of the 
WWW, thus it's quite likely that some of it will fail to meet SGML's 
standards of generality.)  Furthermore, the availability of the ':'  
(or whatever) would allow all the work in this area to stay at all times 
within the bounds of XML/SGML legality, thus (I think) greatly limiting 
the chances of the process going off the rails in a damaging fashion.

This process has been educational at a bunch of levels.  Let's focus
on the problems that are in our mandate; there are a ton of them.

Cheers, Tim Bray
tbray@textuality.com http://www.textuality.com/ +1-604-708-9592
Received on Monday, 23 June 1997 02:55:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:11 UTC