[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: using namespaces to version
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) ...
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|