Another look at namespaces

[Tim Berners-Lee]

-----Original Message-----
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
definitive
schema (the resource identified by the namespace URI) for making
definitive pronouncements by the language publisher in the form of any of
the above.

>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
around (appended):

 "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
>short-term implications?
>
>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
convenience.


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
other documents.


>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
and interoperability...

If you mean define a clean superset language and its grammer and give
it a label then I would be all for it

> -Tim


Tim

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
>============================================
>
>SUMMARY
>
>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
DNS
>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.
>
>DETAILED EXPLANATION
>
>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
reused,
>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
designed to
>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
>policy choice.
>
>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.
>
>CONCLUSION
>
>
>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;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)