Re: using namespaces to version

[james anderson <james.anderson@setf.de>]

Some of this list's readers thought it was not a good idea to involve
the URI reference which names a given namespace in the task of
identifying structural constraints for and/or associating a semantic
with the names which the namespace comprises. The present discussion
seems likely to hearten their skepticism.

At this stage, where there is no universal agreement as to how, or even
whether, to use a namespace name to identify and/or locate a schema
and/or document description, to turn around and propose colloqualisms
from a URI, or more specifically the URL, interpretion domain as the
basis for a mechamism to serve to inflect distinction and identity among
names is, well, an unexpected tactic. This reader would hope that the
tactic does not succeed.

David Carlisle wrote:
> [... in reply to]
> > Wouldn't it be useful to have the namespace on the <apply> element define
> > what the correct content model is?
> 
> Oooh touching on religous debate there:-) but a namespace only defines
> one thing, its name.
> 

While true, if limited to that, no namespace would be terribly useful. A
namespace's utility derives from the set of names which it comprises as
well as from the stability of the namespace's identifier. If the notion
of a "universal" name is to mean anything, then a name's identity must
be constant over a longer time period than that filled by processing of
a single document. For this to be true, not only must the name of the
namespace be persistent, the relation to the constituent names must
persist as well.

On the other hand, that stability would likely be counterproductive were
it to preclude reusing and combining descriptions which employ such
names. Which argues for a means to describe relations among namespaces
and names.

As I work in a base environment which supports such descriptions (common
lisp), I describe these relations in the base language - independent of
the XML encoding. Universal names are modeled as symbols and lisp's
package system provides those primitives necessary to contend with
versioning issues. The method of modeling names as symbols is common
among lisp-based parsers, which means that any one of them could handle
versioning. It's a mechanism which has been used to version and compose
software systems for decades. I'd be interested to hear whether
versioning "documents" presents different problems.
 
In response to this thread, I wondered how much of the package mechanism
would be needed to facilitate xml versioning. The following operators
appear sufficient

ns_make
 defines a namespace. this is a useful constraint, but is not
 strictly necessary.
ns_export
 specifies those names which should be inherited from a given
 namespace when another namespace "uses" it.
ns_import
 specifies those names to be inherited explicitly by a given namespace.
ns_shadow
 specifies those names to be present distinctly in a given namespace
independent of
 implicitly inherited names.
ns_use
 specifies relations among namespaces. the using namespace inherits
 the exported names from all used namespaces.

where these operators are made available through processing
instructions, it is possible to encode versioning information as
"exports" for those names which denote the reusable features of a given
document form and "shadows" for those names associated with features which
are to be changed. where no distinct name is specified, the inherited
name is recognized.

in the example below, {namespace/1}a is identical with {namespace/2}a,
and the same is true for the respective {*}b names, while {namespace/1}c
and {namespace/2}c are distinct.

(defParameter *document-string*
  "<!DOCTYPE doc [
     <?ns_make      namespace/1?>
     <?ns_export namespace/1 a b c?>
     <?ns_make namespace/2?>
     <?ns_shadow namespace/2 c?>
     <?ns_use namespace/2 namespace/1?>
     <!ELEMENT ns1:doc (ns1:a, ns1:b)>
     <!ATTLIST ns1:doc xmlns:ns1 CDATA 'namespace/1'
                       xmlns:ns2 CDATA 'namespace/2' >
     <!ELEMENT ns1:a ANY>
     <!ATTLIST ns1:a ns1:att1 CDATA ' a default' >
     <!ELEMENT ns1:b ANY>
     <!ELEMENT ns1:c ANY>
     <!ELEMENT ns2:c ANY>
     <!ATTLIST ns2:c ns1:att2 CDATA 'present in namespace/2 c only' >
     ]>
   <ns1:doc>
     <ns2:a xmlns:qwerty='namespace/1' qwerty:att1='explicitly'
            xmlns='namespace/2'>
      <b>
       <c/></b></ns2:a>
     </ns1:doc>")

(write-node (document-parser *document-string*) *trace-output*)

;; yields

"<ns1:doc xmlns:ns2='namespace/2' xmlns:ns1='namespace/1' xmlns=''>
     <qwerty:a xmlns:qwerty='namespace/1' xmlns='namespace/2' qwerty:att1='explicitly'>
      <qwerty:b>
       <c qwerty:att2='present in namespace/2 c only' /></qwerty:b></qwerty:a>
     </ns1:doc>"




The processing instructions are implemented as direct interfaces to the
respective base functions. I include below links to descriptions for the
curious reader. I wish I could provide a link to a general description
of symbols and packages, but I know of no online version.

export
 (http://www.xanalys.com/software_tools/reference/HyperSpec/Body/fun_export.html#export)
import
 (http://www.xanalys.com/software_tools/reference/HyperSpec/Body/fun_import.html#import)
make-package
 (http://www.xanalys.com/software_tools/reference/HyperSpec/Body/fun_make-package.html#make-package)
shadow
 (http://www.xanalys.com/software_tools/reference/HyperSpec/Body/fun_shadow.html#shadow)
use-package
 (http://www.xanalys.com/software_tools/reference/HyperSpec/Body/fun_use-package.html#use-package)

...