[slightly edited] From: Arjun Ray Newsgroups: comp.infosystems.www.authoring.stlesheets Subject: Using XSL or CSS to Display XML like a normal html page? Date: Wed, 26 May 1999 19:01:00 -0400 Organization: FUDGE Dispersal Systems Message-ID: <0euiot4uvoushj2sa0dg3bfqjvh89t1mbk@4ax.com> In , dba...@ws23.fas.harvard.edu (David Baron) wrote: | In article <37fa1b15....@news1.newscene.com>, Arjun Ray wrote: | > The XML namespace spec [says] that an URI can be used to qualify a | > name in order to make it globally unique. [So,] there specifically | > are *no* semantic connotations to the "namespace" represented by | > the URI. It's *supposed* to serve a syntactic purpose only. | | Although the namespaces spec itself doesn't define the meaning of | any namespaces, the specs for various applications do. I thought that | was the purpose of the spec. Indirectly. The spec per se has no purpose other than to avoid saying anything definite about something that rates to makes no sense without some definite statement. Geddit? (Yeah, it really is that bad.) | Different applications have defined meaning of namespaces in different | ways. [...] People seem to be using de facto namespace names for some | other specs (e.g., MathML), which rather annoys me. They ought to | be defined. Yes, but there's more going on here. The "namespace" is a URI, not a name. Look at what bothers you: "de facto namespace *names*" [emph. mine.] Somebody sees the 'MathML' prefix and says "Oh! I know what's going on here!", when in fact he's not supposed to know what's going on here unless he recognizes the regular part of the name as and when prefixed by the URI. 'MathML' was merely a circumstantial, instance- specific shorthand. Inter alia, replacing the 'MathML' prefix with something like 'Foo' should *not* make any difference, because the prefix per se - 'MathML' - has no semantic significance. See James Clark's explanation, especially the alternative non-XML syntax which better expresses what a processing application is supposed to "see": Well, then, what does the URI-prefixed name "mean"? That's the point at which the namespace spec stops, having accomplished nothing except to define a syntax, and a convention, for a purportedly "universal" name. The point, however, is that a universal (i.e. globally unique) name by itself is quite useless. What's really wanted is that a definite semantic category be identified. This, apparently, is what the namespace URI is supposed to do: itself uniquely represent some schema in which this universal name is intelligible. See Tim Bray's explanation of the namespace spec: But there's a nudge-nudge-wink-wink in all this... | > And so, now, you have a "common sense understanding" of namespaces | > quite at odds with the formal spec, | | With which part of the formal spec is this at odds? | | I think the first three paragraphs of the spec itself seem to say that | the intent is to assign meaning to XML elements: Look at the third paragraph: | These considerations require that document constructs should have | *universal names, whose scope extends beyond their containing | document*. [emphasis mine] The scope is about names (not meanings!) and the spec defines a syntax for "universal names". Yes, it can be argued that the examples point toward intended use, but the spec only says: : The attribute's value, a URI reference, is the namespace name identifying : the namespace. The namespace name, to serve its intended purpose, should : have the characteristics of uniqueness and persistence. It is not a goal : that it be directly usable for retrieval of a schema (if any exists). The spec does not offer a formal statement of 'intended purpose' - or even a means of determining it in a machine processable way! - only some "motivation and summary". That's the nudge-nudge-wink-wink. In other words, the spec is *only* about "universal names". So what's the problem? Just this: "...document constructs should have universal names" is one huge whopping non-sequitur! It just ain't so... | I think this description is similar to its current use, but not quite. | It describes different namespaces being used to indicate different | meaning to *different* applications, while current usage seems to be | that the different namespaces indicate different meaning to the *same* | applications. I wouldn't really call that "at odds." The point hinges on whether a universal name tells you what something is or what it means. This a matter of recognizing the name. The spec focuses on a choice of names (via URIs) such that they rate *not* to be recognized unless specifically triggered for. Actually, the whole business of a universal name for an element type or attribute is a maguffin. Yes, it can be a sufficient condition to identify a semantic category, but it is not necessary. In fact, the *real* requirements can be expressed as: (1) Unique identification of a semantic schema. (2) Identification of a role within that schema. (3) Association of a part or aspect of the current document with that schema-defined role. Notice that nothing directly was said about *names*, let alone ones of some supposedly universal character. That's because names per se are purely instrumental. It's an integral part of the SGML/XML formalism to have complete freedom in choosing the names with which to represent one's own data. So, for the requirements, we need to use (at least) three names: one for the part, one for the schema, and one for the role; and a definitional mapping which says [schema] -> some semantically meaningful system [role] -> some specified aspect of [schema] [part] -> "means" [role] in (relation to) [schema] in effect "We reference [schema] to associate [role] with [part]" +--------+ +----------+ +--------+ | [part] | <=== | [schema] | ===> | [role] | +--------+ +----------+ +--------+ Of the three names, only [role] will be constrained, as it's defined in the external schema. For an application, [role] will be the well- known name we'll want to recognize anyway, so this isn't a problem as long as its *encoding* doesn't clash with other markup. [part] and [schema], however, can be anything we please. To associate an element type, the markup can be as simple as . Attributes are only a little trickier: . Note that the 'schema' attribute on the element need not share the same name with the 'schema' attribute on : in general, we'll need two names for the [schema] association, one for element types and one for attributes. With the direct markup taken care of, we now need a means to identify these two attributes as "schema-mappers", and the identifiable scheme to which these mappers apply. But, if you think about it, this is also a syntactic exercise with definite semantics: to associate an external URI *known to be semantically significant* with two internal attributes. For simplicity, consider a processing instruction: Can the significance of be left as an exercise for the reader?;-) That's it. We're done. With absolutely zero new syntax. A formal spec for the internal syntax of the processing instruction is all it takes. Not only do we get syntactic disambiguation for name clashes (as the clashing names from the external schema are tucked away in attribute *values*), we also get association with a persistent and unique name (the schema's URI.) We also get *multiple* associations for the same [part] if needed: we just use two more attributes with names of our *own* choosing. Instead, just to give a bunch of C++ programmers a warm fuzzy feeling, the namespace spec offers some monkey business with URIs as parts of universal names or somesuch and colons and whatnot. Bleagh. | I don't think it is the job of the namespaces spec to define what URIs | map to what meaning. I think that is the job of the applications. It's not really up to applications either. The only issue is whether applications *recognize* the URI (at that, as a schema identifier.) | I think namespaces are useful because they allow things from different | specs to be mixed in a sensible way. What about multiple role associations? | The MathML spec added an element to HTML so that MathML could be | included. This won't need to be done anymore (although it does | require changing the concept of validity). Yes and no. It may suffice to require that only mapped transforms of a document validate (i.e., with respect to the DTD of the *relevant* schema.) Since XML documents don't necessarily carry DTDs, this is in fact about the best we can ask for in practice, anyway. | Although I wish some other things had been worked out sooner (like | schema validity), I think the current use of namespaces is a good | thing. It's a reinvention of the wheel, and badly at that. | > The really shoddy part of this whole business is that SGML already | > had an answer for the problem of attaching semantics: architectural | > forms. | | It's probably too late to replace namespaces, but it still sounds | interesting. Any references? For this particular discussion, I'd suggest this first: As another example, see Eliot's note on RDF: Robin Cover's SGML/XML page has some stuff on AFs :ar -- "The bottomline is that it is really difficult to solve a problem when the problem does not exist." - Masataka Ohta.