[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Another look at namespaces
From: Andrew Layman <andrewl@m... >With all due respect to Simon St. Laurent, I believe that Tim Berners-Lee >was correctly precise when he wrote "the document corresponding to the >namespace URI becomes >the place where the namespace-author can put *definitive* >information about the intent of the namespace." (Emphasis in the original). The only information that properly belongs in a namespace is a list of names. All other information, however convenient, is not namespace information but something else: what is this "intent" business? There is no mention of "intent" in the namespaces spec that I recall, quite the opposite. The fundamental justification for namespace is to be free from intent. There is no W3C method to define a namespace as list of names. There is no W3C method to declare which schema should be used, akin to the stylesheet declaration. In the absense of these, of course people will try to turn namespaces URIs into schema declaration URLS. The W3C should provide a proper way to define namespaces (as simple lists) and a way to declare schemas. (Furthermore, the idea of a namespace-author being in some way the controller of the resource for a schema is bad; a schema identifier (or a namespace list) should be identified using the URI equivalent of a Formal Public Identifier: I can ask some service to provide me that schema (or that namespace list) in any format that anyone has chosen to make available.) >While there are many processes that can be applied to a document, and >correspondingly many specifications of those processes, there can be, for a >given term in a namespace, at most one correct *definition*. Again, the only declaration information that is proper to a namespace is a list of names. A content model is a schema, and nothing to do with names in a namespace, in particular. >[Someone] wrote that, although a schema may be somehow associated with a Me among others >namespace, the "meaning" of markup will be determined in a number of ways >such as style sheets, or procedural code, or maybe the schema. I believe >this understates the importance of the schema. A schema makes a >contribution to the Infoset. It does this by providing default values and -- >under some recent proposals -- by indicating type information, which may be >considered also a form of default value. Elements defined by a schema, when >used in an instance document in a validating processor, will have these >default values available, and this fact is pertinent to the author of the >document. This means that an element is incompletely read if the schema for >it is not read. This assumes that default values are not conditional or parameterized, which in turn assumes a particular form for schemas. But the current Infoset draft only has "the information available in a well-formed XML document". So there are levels of Infoset depending on which data is considered, in progressive fashion. In s. 7 "What is not in the information set": 1. The information in the XML declaration and text declarations. 2. Element content models from ELEMENT declarations. 3. The grouping and ordering of attribute declarations in ATTLIST declarations. So Andrews view seems novel. In DOM level 1 also there is no access to content model information, which suggests that the incompleteness of an element without a content model is minimal for basic use of that element. Canonical XML does not include DTD or schema. (Furthermore, some people have reservations that default values are in fact part of a schema at all. ) >Unlike the various processings that may or may not be applied to a document, >a cited schema is part of the information conveyed by the document. When a >namespace has an associated schema, that schema is part of the input to any >further complete processing of the referencing document. A schema is not on >par with other forms of processing that might be specified, say by style >sheets or procedural code. It is prior to other processing. Again, Andrew is simply conflating schema and namespace. The idea that he and Tim are putting forward is that a language is defined by a single set of content models; this confuses "language" with "grammar" and is disproved by long-standing SGML practise, in which variants of a language can be defined in the same DTD (selected by marked sections, or by simply overriding parameter entity declarations). I think the problem is the bad idea that content models *define* a language rather than simply *describe* or *declare* it. The "blink" element is not strict HTML; it is only an artifact of the formalism used to describe HTML (content models on the child axis) that using a blink attribute should require the child element to be transitional HTML. There have been so much criticism of DTDs and their particular limitations of expressiveness, yet this namespace issue utterly is dependent on a DTD-based understanding of what a schema should be. An element is not defined by its content model, unless it and its content model are highly coupled semantically, such as tables and rows. But frames and the root html element are not highly coupled semantically. DTDs and content models (on the child axis) provide no way to model this: we either have ANY or a highly coupled content model. Take the example of <p> and <blink>: these are not semantically coupled element types-- the <blink> element type adheres to running text and the <p> element uses running text. If the <blink> element is removed, it is the declarations for running text that should be changed, not the declarations for <p>. DTDs only provide parameter entities for this, which disguises this basic modeling truth. The XML Schema draft got it more right by providing archetypes as a first-class object. >Further, I expect that one can argue that a namespace is an abstract concept >denoting a set of names, and this argument is true, so far as it goes, but >it does not go far enough: For specific processing, to make use of a >namespace one needs to know what names are in it, which are not, and what >the meaning is for each name Here is the crux: Andrew is saying a namespace mechanism should provide more than just a space of names! He says it should also provide meanings. If it does so, it is not a namespace, but a schema. Andrew is saying that we should not have namespaces but schemas. This is a legitimate view, but it utterly flies in the face of the current spec and all previous pronouncements on it. If W3C says a namespace is a schema, they should withdraw the XML Namespaces Spec immediately. As I emailed a month ago, Namespaces is dead. Not by neglect but by abuse. Rick Jelliffe xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1 To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
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
|