Another look at namespaces

[Len Bullard]

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.  
Correct?

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.

Len Bullard



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;
(un)subscribe 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)