XTM Uses Scope For Languages
Date: Sat, 02 Feb 2002 14:30:22 -0600 From: "Steven R. Newcomb" <email@example.com> To: "Bandholtz, Thomas" <firstname.lastname@example.org> Cc: topicmaps-comments <email@example.com>, firstname.lastname@example.org Subject: multilingual thesaurus - language, scope, and topic naming constraint
"Bandholtz, Thomas" <email@example.com> writes: > I never understood why XTM uses scope for languages. > ISO/IEC FCD 13250 does not recommend that. > XML itself has defined the xml:language attribute, > i.e. see: << [Definition:] language represents > natural language identifiers as defined by [RFC > 1766]. The 7value space7 of language is the set of > all strings that are valid language identifiers as > defined in the language identification section of > [XML 1.0 (Second Edition)]. The 7lexical space7 of > language is the set of all strings that are valid > language identifiers as defined in the language > identification section of [XML 1.0 (Second > Edition)]. The 7base type7 of language is token. > http://www.w3.org/TR/xmlschema-2/#language > The scope of GEMET is Environmental Protection, and > not a bunch of languages. > So you might use: > > <basename xml:lang="en">economics</basename> > etc. > I know this does not conform with XTM - but sorry to > say using scope for language does not conform with > XML :-(. Bernard's sample shows the problems very > well. They would disappear when we use xml:language > instead of scope. This would also modify the merging > rule: ... having the same basename in the same scope > ... and the same language! (allthough even this does > not really work because of homonyms) I think several points need to be made here. (1) Not all applications of Topic Maps require languages to be identified. (For that matter, not all applications of XML require languages to be identified.) In order to appear in a topic map, each natural language must itself be the subject of a topic. The topics that are implicit in the XTM syntax itself were strictly limited to those that were considered necessary for *all* (or virtually all) Topic Maps applications. The XTM syntax has ways of making any subject, including subjects that are natural languages, the subject of a topic. (2) There are lots of "standard" namespaces in use with XML, and more are added from time to time. Each of them is implicitly founded on some set of specialized subjects. The XTM syntax should not (and, in fact, cannot) be expanded to provide special syntactic features for each and every subject. Consider the ODA experience, and the 28001 experience, both of which are cautionary tales. One of the lessons that all XML people should bear in their minds is that one syntax never fits all, at least partly because one set of semantics can never be enough. At the same time, one set of semantics can easily be too many to be useful. Syntaxes that never stop growing are like cancers: they get larger and larger, consuming more and more resources, until they finally either kill their hosts, or they are excised. (3) XTM was designed to be maximally intuitive. We deliberately avoided, wherever we could, situations in which "hidden magic" processing -- processing that would require special treatment of special syntactic cases -- would have to occur. Your proposal that the value of the xml:lang attribute be treated as a member of the operative scope is exactly the kind of thing we labored to avoid. We believed that, if a topic is supposed to be considered a member of a scope, then, by Golly, it should appear inside the corresponding <scope> element. Otherwise, the syntax becomes unlearnable, because it is too tricky. (4) Nothing prevents a topic from having a subject indicator that references the relevant specification for xml:lang. In fact, that's a good idea! Such a topic can then appear in a scope, like any other topic. Users can get all the standardizing benefits of xml:lang, but without establishing a precedent in which XTM cannot say "no" to any new "xml:" attribute that comes along, for any new class of subjects (why stop at languages?), thus making XTM become yet another bloated necrotic tumor on the SGML/XML landscape, and the subject of yet another cautionary tale. (5) If you want to design your own syntax for XML Topic Maps, you are free to do so, and you can bring into it every kind of topic that is implicit in every kind of XML namespace name, if that's what you want to do. Eventually (but not just yet), you'll be able to define a processing model for your syntax that will enable your topic maps to be merged with all others, just as if they were all notated in a single standard syntax. (Whether anyone will pay attention to your syntax, and its processing model, is a separate issue.) This syntax-unification capability is one of the goals of the modeling work that is being done in ISO SC34/WG3. The initial impetus for this work was that there are already two standard syntaxes for Topic Maps: HyTM and XTM. > The scope of GEMET is Environmental Protection, and > not a bunch of languages. (6) In a topic map, either a subject is represented as a topic, or it is not represented at all. Note: In the foregoing sentence, I did *not* say: In a topic map, either a subject is represented as a <topic> element, or it is not represented at all. In an XTM-conforming syntactic instance topic map, there are many topics that are not represented as <topic> elements. A base name, for example, is necessarily, at the lowest level, a subject, even though there is no corresponding <topic> element whose subject is that base name. If you want to understand either XTM or HyTM, it's imperative to understand what are all the implicit subjects that must, ultimately and fundamentally, be handled as topics. If, for example, a subject appears in a scope, that subject, like all other subjects, is represented as a topic. There is nothing else that it can be, at least not in the Topic Map paradigm. Some eminent Topic Maps practitioners have suggested that, after topic map processing/merging, there should still be a distinction between topics that were the subjects of <topic> elements, and all other topics. Maybe this requirement is one that you would like to voice your support for, so that, for example, in your GEMET topic map, you can automatically distinguish between the topics that you chose to specify via <topic> elements, and all others. Such a distinction could be used to control the way a rendering application behaves, so that you can specify <topic> elements only for the subjects that are directly relevant to GEMET, and have only those topics be rendered in certain circumstances. The same goal could be accomplished more flexibly by asserting that all your GEMET topics are instances of the GEMET class. This technique would leave you in a position to use <topic> elements for auxiliary subjects, without polluting your specially-privileged set of GEMET topics. What do you think? Should it be a part of XTM processing that every topic that corresponds to a <topic> element is automatically an instance of the "came from an XTM <topic> element" class? Or is this extra overhead going to benefit only a small group of practitioners, who could have achieved the same goal more flexibly by explicitly asserting which subjects should be treated as "full-fledged" topics (whatever they might mean by that)? -- Steve Steven R. Newcomb, Consultant firstname.lastname@example.org voice: +1 972 359 8160 fax: +1 972 359 0270 1527 Northaven Drive Allen, Texas 75002-1648 USA
Prepared by Robin Cover for The XML Cover Pages archive. See related references in (1) the news item, "OASIS Technical Committee to Define Published Subjects for Geography and Languages"; (2) "(XML) Topic Maps."