Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Suggested guidelines for using local types. (was Re: Enlightenmentvi
 James Clark wrote: > I would suggest instead that the question of whether to namespace qualify > should be based on the answer to the question: what is the namespace that > defines the meaning of this element? If there is such a namespace, then the > name of the element should be qualified with that namespace. If there is no > such namespace, then then name of the element should not be > namespace-qualified. I believe that it is necessary to extend this argument further and suggest that 'meaning of this element' signifies, as a practical matter, the processing which a given node will apply to an element or to any other structural artifact of an instance document. I think that James Clark implies as much when, e.g., he differentiates step 2 > 2. Another step down, would be something like <h1> which cannot occur as a > root, but has consistent content model and processing wherever it occurs. from step 3 > 3. Another step down, would be something like a <title> element that can > appear as the child of a <chapter>, <section> or <subsection>. It has the > same content model, but the processing may partly depend on the context on the basis of how they will be processed. In the end, questions of 'type' (in both the senses which have been used in this thread) and of the scope of namespaces are reduced to a simple locally-specific question of identification: whether there is a process available to a particular node which might usefully (as useful is locally understood by that node) be applied to an element (or 'type') or to any other structural artifact of a particular instance document. Because this is a two-sided function of identification--finding in the instance document structures which may reasonably and usefully be instantiated in the particular form expected by a locally available process, and choosing from the locally available processes one or more which may usefully be executed, given particular artifacts of a particular instance document--any such identification is utterly specific to a particular instance document, on a particular occasion, in the hands of a particular processing node. Both validation in the traditional DTD sense and schema validation resolve ultimately to this question of whether, and then specifically, how, to instantiate data in a form which is specific to, and therefore implies as well as triggers the execution of a particular process. The criteria of this identification are the structure and the provenance of the instance document at hand, as understood by a processing node. Element names (GI's, 'types' in the markup sense) are one *lexical* clue in making such an identification. Namespace indication, conforming to the Namespaces in XML Recommendation, within a instance document is another such *lexical* clue to the provenance and structure to be identified in the instance document at hand. The conformance of document, or of some structural artifacts of it, to a DTD or schema--whether specified by that document or not, but available to a particular node at which that document is processed--is a more abstract, and therefore less concretely lexical, clue to the appropriate processing to be executed, and therefore to the concrete form in which data must be instantiated to satisfy the requirements of that process. Yet the appropriateness of using any such schemata on any occasion depends first on the specifically lexical processing of an instance document, to establish a reasonable correspondence of the structure and provenance of that instance to the expectations of the more abstract schematic model. In other words, the effective namespace or, more accurately, the identification of the provenance and structure of an instance document or of any structural artifact of it, is inescapably bound to 1) the specifically lexical form of that instance, 2) the abstract models of provenance-plus-structure, whether namespace-compliant DTD's, schemas or other, available to the node processing that instance, and especially 3) the specific form of data instantiation which the process to be executed requires. In arguments which while attempting to establish the appropriate scope of particular elements continually return to questions of processing, this thread illustrates the practical inseparability of the three. In that light, the question of local versus global scope is negligible: effectively it resolves to the fairly uninteresting question of whether the appropriate process to be applied (and by implication the particular instantiation of data which that process expects) is a process (and an associated instantiation of data) which is somehow 'unique', or at least peculiar in its application, to the particular processing node on the particular occasion, or whether it is a process (and associated instantiation of data) which that node has received from 'somewhere else', along with a fixed association of that process to the specific naming of particular structural artifacts (GI's, types) and to the specific identification of provenance (namespacing). Quite simply, this is no more than the question of whether the form in which a particular processing node has identified its association of the names of structural artifacts (GI's, types) with abstract structures (DTD's or other schemata) and with a system of labeling provenance (namespacing) is shared--an shared at the simple level of vocabulary--with other nodes, or not. In practice, whether the name (and therefore 'type') of a particular element or other structural artifact of an instance document is judged on the basis of the vocabulary of that instance document to be local or global in scope matters very little. What matters very much is how a particular processing node will instantiate data and therefrom execute process on a particular occasion. This is a larger question in which the apparent scope of a particular structural artifact, as indicated either by the syntax of an instance document or by a schema applied in instantiating data at a processing node, is unimportant compared to the actual scope of that artifact as realized in the particular instantiation of data for processing on a given occasion. Respectfully, Walter Perry 
|
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
|
|||||||||
