Re: Suggested guidelines for using local types. (was Re: Enlightenmentvia avoiding the T-word)

["W. E. Perry" <wperry@fiduciary.com>]

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