Another look at namespaces
cbullard at hiwaay.net
Sat Sep 18 18:28:21 BST 1999
David Brownell wrote:
> That was the gist of Tim's point that the "definitive"
> schema would be found at the end of the namespace URI.
> Something can't be both optional and definitive in that
> way ... if it's optional, some other way could be be
> at least as correct/definitive.
Try a change in terminology here: record of authority. It
has a precise meaning in a contracting environment and a
contracting environment is what is required for namespaces to
be applied beyond its specification. Note that a record of
authority is that artifact by which parties are contractually
obligated, testable, and litigable.
In the process of creating documentation, only in very restricted cases
is the philosophy
of "conversation from author to reader" useful. When this philosophy
was advanced in the IETM community in the early 90s (See
Eric Jorgensen), it was in the context of a type of document
used in diagnostic systems where directive statements encoded
as dynamic node navigation was used: technical manuals and wizards.
However, there is an entirely different system of document production
and use in place to create these "conversations". When creating
documents as the record of authority for say, a system, there
will be multiple instances as the document is changed version by
version to correspond with the emerging design, the testable
product, then the product post Product Acceptance Test. At
each juncture, a unique record of authority will exist whose namespace
is or can be different. These differences may be seen as
the different names/element types that are applied within
the scope of a nested or linear set of processes. The scheduling of
processes, the binding of namespaces within these processes,
an the publication of a final record of authority for acceptance
are essential to contract based commerce. I note that commerce
is not the only application but that it is a complex case which
obviates simpler notions.
1. The Namespaces specification only assert the role of the
namespace as a means to make a string unique within a scope.
It goes no further. This does not make the spec wrong or
inadequate but it limits its role as a record of authority
in contracts to which it is applied. It also means the
silence referred to in this thread is appropriate with
regards to the spec if not to the principal authors
(separate politics and law for the sake of progress).
2. A namespace is a URI/URN. The role of the URI/URN as a
record of authority is defined by a separate specification
by the IETF (Correct?). The role is as a means to locate a
resource. The specification does not define the resource.
3. By a third agreement, it is possible to define the nature
or use of the record of authority of a resource. Tim Bray and
others are correct in stating that this cannot in all roles
be a schema given that there are better alternatives in given
processes (eg, use of applet, schema, other programs, natural
language text, or even a registry or record that specifies any
and all of these). In effect, this is negotiable or assertable
in a record of authority.
If the namespace is to assume a role (by dint of formal specification or
local contract) as the identifier and means of locating a
record of authority, it must be useful in a dynamic process
and must be flexible with regards to the implementation of the
tools used in that process. I suggest that the concept of negotiation
(eg. MIME) is still the most effective means we have at this time
for dealing with this.
Definitiionally, HTML is the weakest case.
It is a user interface/presentation language and its
element types are only weakly associated with the semantics
of the information if tightly associated with the semantics
of presentation and navigation. Multiple namespaces in XHTML
are not efficient but they are not unexpected. Any review
of preexisting markup schemas such as MIL-M-28001 reveal that
any schema applied to a very large domain over time by multiple
contracting parties becomes very large, very cumbersome, and
very difficult to apply. Because of this, it is more likely
that the multiple namespaces as separate languages are more
tractable if for no other reason to encourage the older and
less useful languages to die off. This is a fundamental
of information ecologies.
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 (un)subscribe, 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