Another look at namespaces
timbl at w3.org
Wed Sep 29 00:05:18 BST 1999
From: Tim Bray <tbray at textuality.com>
To: XML-DEV <xml-dev at ic.ac.uk>
Date: Friday, September 17, 1999 7:14 PM
Subject: Re: Another look at namespaces
>At 09:18 AM 9/17/99 -0400, Tim Berners-Lee wrote:
>>From: Tim Bray <tbray at textuality.com>
>>>Among other things, I don't believe that most
>>>interesting namespaces *have* definitive information, but have semantics
>>>that are communicated via some messy combination of schemas, stylesheets,
>>>prose documentation, and running code.
>>We either have a different use of words or a very serious
>>problem. Whereas with natural langauge, meanings change and
>>grow and everyone has slightly different associations with a word,
>>in computer languages we need to build on top of XML we need
>>to have the ability to define meaning precicely in terms of
>>other existing languages.
>Actually, Tim B-L and I are both advocates of moving as much semantics as
>possible from idiosyncratic impenetrable procedural code and woolly forests
>of prose into declarative schemas so that you can start to use some
>knowledge rep tricks and do a bit of meaning-discovery, not just the
>resource-discovery enabled by the current Web. This is what Tim calls
>"the semantic web" in his platform speeches, and its foundation is
>RDF and RDF style schemas. I'm onside with this.
>Perhaps the disagreement (if any) is on the degree to which this
>is possible. There are going to be lots of languages invented, and
>while I believe that we will get increasingly better definitional
>machinery as time goes on, I see no reason to believe that any of
>the following are going away:
>- human-readable documentation
>- messy procedural code that actually does something useful with the data
>- stylesheets (plural)
>- related resources containing hyperlink networks
>- related resources containing RDF assertions in some vocabulary
>- transformation specs along the lines of XSLT
I think that the essential thing for me is the availability of the
schema (the resource identified by the namespace URI) for making
definitive pronouncements by the language publisher in the form of any of
>and so on and so on.
>What bothers me is the notion that among all these things, the schema
>is somehow privileged and special. I think that which of the above
>laundry-list you care most about is very highly application-dependent,
>data-dependent, and rather wholly unpredictable in the general case.
There is however, whether you physically retrieve it or not, something
fundamentally important about the definitive meaning of a language.
Brain Carpenter summed it up will in the IAB statement which just came
"In the case of a public communications system this condition of a common
symbol set with a common semantic interpretation must be further
strengthened to that of a unique symbol set with a unique semantic
interpretation. This condition of uniqueness allows any party to initiate a
communication that can be received and understood by any other party. Such
a condition rules out the ability to define a symbol within some bounded
context. In such a case, once the communication moves out of the
context of interpretation in which it was defined, the meaning of
the symbol becomes lost."
>I suspect that the proportion of real-world applications that actually
>use the schema at run-time will be moderate at best - schemas come more
>usefully into play in application design, authoring support, and so on.
>Perhaps Tim B-L thinks that this proportion will in fact be quite high?
It is not a question of the proportion but of the principle.
XML is going to be used for such a vast array of applications
that to try to guess what sorts will be most numerous is IMHO
a dangerous idea - as you point out. However, building the
system cleanly and so that things have well defined meanings
is the way to prepare for all kinds.
>This is a reasonable disagreement, and we've all been fooled by
>technology enough times to have learned humility.
>So.......... where do we still have disagreements with concrete
>1. I'm convinced that the namespace mechanism, while it's useful
> for what it is, is hopelessly inadequate as a tool for direct
> mapping between instances and schemas.
I am disappointed to hear that from an author of the spec.
(Can I say " .... and definitive schemas?")
> We need at least one level
> of indirection, i.e. the packaging work that's hanging fire in
> the W3C XML activity.
Packaing is not indpirection, its putting >1 document in one document for
Indirection you can get in many ways just by using a namespace URI
in a suitable scheme (like http) which allows indirection, caching etc.
>2. For this reason, I think that the correspondence between
> namespaces and DTDs in XHTML 1.0 PR doesn't do a good job of meeting
> the needs of either people who need schema discrimination or of
> people who think HTML-is-HTML.
The "HTML-is-HTML" phrase suggests documentation of the suboptimal world
in which anything goes. I am against it. I explined why in a keynote
at the Brisbane WWW conference, I tried to explain why in my book, and
http://www.w3.org/DesignIssues/Evoluion (alas corrupted at the end) and
>3. I am astonished and disappointed that the W3C still can't bring
> itself to publish a 3-line note saying that for those who see
> HTML just as HTML, and who want to mix & match those tags with
> others, they should use the following URI as a namespace name for
> HTML: <insert any old plausible namespace URI here>
It depend on wht you mean about mixing & matching.
If you mean a return to the bedlam of HTML 2++-- I dop not
see it a part of leading the web to its full potential though evoluition
If you mean define a clean superset language and its grammer and give
it a label then I would be all for it
in no official capacity
>From: Brian Carpenter <brian at ICAIR.ORG>
>To: IETF-Announce: ;
>Subject: IAB Technical Comment on the Unique DNS Root
>Date: Mon, 27 Sep 1999 16:33:15 -0400
>Sender: scoya at cnri.reston.va.us
>[The IAB has sent the following note to comments at icann.org]
>IAB Technical Comment on the Unique DNS Root
>The Internet, to remain a global network, technically requires the
>existence of a globally unique public name space. The DNS name space is a
>hierarchical name space derived from a single, globally unique root.
>This is inherent in the design of the DNS system. Therefore it is not
>technically meaningful for there to be more than one root in the public
>system. That one root must be supported by a small number of coordinated
>root servers, and administered by a unique naming authority.
>Put simply, allowing multiple public DNS roots would raise a very strong
>possibility that users of different ISPs who click on the same link on a
>web page could end up at different destinations, against the will of the
>web page designers.
>This does not preclude private networks from operating their own private
>name spaces, but if they wish to make use of names uniquely defined for
>the global Internet, they have to fetch that information from the global
>DNS naming hierarchy, and in particular from the coordinated root servers
>of the global DNS naming hierarchy.
>There are two reasons for a single DNS root:
>1. For any communications between two parties to be effective there are two
>essential preconditions: The existence of a common symbol set, and the
>existence of a common semantic interpretation of these symbols. Failure of
>the first condition implies a failure to communicate at all, and failure of
>the second implies that the meaning of the communication is lost.
>In the case of a public communications system this condition of a common
>symbol set with a common semantic interpretation must be further
>strengthened to that of a unique symbol set with a unique semantic
>interpretation. This condition of uniqueness allows any party to initiate a
>communication that can be received and understood by any other party. Such
>a condition rules out the ability to define a symbol within some bounded
>context. In such a case, once the communication moves out of the
>context of interpretation in which it was defined, the meaning of
>the symbol becomes lost.
>Within public digital communications networks such as the Internet this
>requirement for a uniquely defined symbol set with a uniquely defined
>meaning exists at many levels, commencing with the binary encoding
>scheme, extending to packet headers and payload formats and the protocol
>that an application uses to interact. In each case a variation of the
>symbol set or a difference of interpretation of the symbols being used
>within the interaction causes a protocol failure, and the communication
>fails. The property of uniqueness allows a symbol to be used unambiguously
>in any context, allowing the symbol to be passed on, referred to, and
>while still preserving the meaning of the original use.
>The DNS fulfils an essential role within the Internet protocol environment,
>allowing network locations to be referred to using a label other than
>a protocol address. As with any other such symbol set, DNS names are
>be globally unique, that is, for any one DNS name at any one time there
>must be a single set of DNS records uniquely describing protocol
>addresses, network resources and services associated with that DNS name.
>All of the applications deployed on the Internet which use DNS assume
>this, and Internet users expect such behavior from DNS names. Names are
>then constant symbols, whose interpretation does not specifically require
>knowledge of the context of any individual party. A DNS name can be passed
>from one party to another without altering the semantic intent of the name.
>Since the DNS is hierarchically structured into domains, the uniqueness
>requirement for DNS names in their entirety implies that each of the names
>(sub-domains) defined within a domain has a unique meaning (i.e. set of
>DNS records) within that domain. This is as true for the root domain as
>for any other DNS domain. The requirement for uniqueness within a domain
>further implies that there be some mechanism to prevent name conflicts
>within a domain. In DNS this is accomplished by assigning a single
>owner or maintainer to every domain, including the root domain, who
>is responsible for ensuring that each sub-domain of that domain has the
>proper records associated with it. This is a technical requirement, not a
>2. Both the design and implementations of the DNS protocol are heavily
>based on the assumption that there is a single owner or maintainer for
>every domain, and that any set of resources records associated with a
>domain is modified in a single-copy serializable fashion. That is, even
>assuming that a single domain could somehow
>be "shared" by uncooperating parties, there is no means within the DNS
>protocol by which a user or client could discover, and choose between,
>conflicting definitions of a DNS name made by different parties. The
>client will simply return the first set of resource records that it finds
>that matches the requested domain, and assume that these are valid. This
>protocol is embedded in the operating software of hundreds of millions of
>computer systems, and is not easily updated to support a shared domain
>scenario. Morever, even supposing that some other means of resolving
>conflicting definitions could be provided in the future, it would have to
>be based on objective rules established in advance. (For example, zone A.B
>could declare that naming authority Y had been delegated all subdomains
>of A.B with an odd number of characters, and that naming authority Z had
>been delegated authority to define subdomains of A.B with an even number
>of characters.) Thus, a single set of rules would have to be agreed to
>prevent Y and Z from making conflicting assignments, and with this train
>of actions a single unique space has been created in any case. Of course
>this would not allow multiple non-cooperating authorities to assign
>arbitrary sub-domains within a single domain; it seems that a degree of
>cooperation and agreed technical rules are required in order to guarantee
>the uniqueness of names. In the DNS, these rules are established
>independently for each part of the naming hierarchy, and the root domain
>is no exception. Thus, there must be a generally agreed single set of
>rules for the root.
>A PRACTICAL NOTE
>There is one specific technical respect in which the root zone is
>different from all other DNS zones: the addresses of the name
>servers for the root zone come primarily from out-of-band
>information (named.root files from the ISC BIND distribution, your
>ISP, whatever) rather than via the NS RR delegation chain. NS RRs
>for the root zone, while present, are almost irrelevant. In
>effect, every full-service resolver in the world "delegates" the
>root of the public tree to the public root server(s) of its choice.
>As a direct consequence, any change to the list of IP addresses
>that specify the public root zone is significantly more difficult
>than changing any other aspect of the DNS delegation chain. Thus,
>stability of the system calls for extremely conservative and
>cautious management of the public root zone (low churn rate,
>relatively tight update coupling between the servers, etc), because
>it's very difficult to route around a misbehaving root server.
>The DNS type of unique naming and name-mapping system may
>not be ideal for a number of purposes for which it was
>never designed, such a locating information when the user
>doesn't precisely know the correct names. As the
>Internet continues to expand, we would expect directory
>systems to evolve which can assist the user in dealing
>with vague or ambiguous references. To preserve the
>many important features of the DNS and its multiple
>record types --including the Internet's equivalent of
>number portability-- we would expect the result of
>directory lookups and identification of the correct names
>for a particular purpose to be unique DNS names that
>are then resolved normally, rather than having directory
>systems 'replace' the DNS. There is no getting away from
>the unique root of the public DNS.
> Brian Carpenter
> IAB Chair
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev