ISO/IEC JTC 1/SC34 N0270

ISO/IEC Logo

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

Title: Response to SC 34 National Body Comments on N220 (N260)
Source: Michel Biezunski, Steven R. Newcomb
Project: Topic Map Models
Project editors: Michel Biezunski, Martin Bryan, Steven R. Newcomb
Status: Editors' Draft
Action: For review and comment
Date: 30 November 2001
Summary:
Distribution: SC34 and Liaisons
Refer to: 220, 238,239, 260
Supercedes:
Reply to: Dr. James David Mason
(ISO/IEC JTC1/SC34 Chairman)
Y-12 National Security Complex
Information Technology Services
Bldg. 9113 M.S. 8208
Oak Ridge, TN 37831-8208 U.S.A.
Telephone: +1 865 574-6973
Facsimile: +1 865 574-1896
E-mailk: mailto:[email protected]
http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm

Ms. Sara Hafele, ISO/IEC JTC 1/SC 34 Secretariat
American National Standards Institute
25 West 43rd Street
New York, NY 10036
Tel: +1 212 642-4937
Fax: +1 212 840-2298
E-mail: [email protected]



Response to SC 34 National Body Comments (N260) on N220

Version: 0.1.0
Date: 2001-11-30
Editors: Michel Biezunski, Coolheads Consulting Steven R. Newcomb, Coolheads Consulting

Response to SC 34 National Body Comments (N260) on N220

Japan

1. The descriptions: "Copyright 2000-2001 TopicMaps.Org. All rights reserved. Permission to use, copy, modify and distribute the XTM ........ purpose. It is provided "as is" without expressed or implied warranty." should be indicated as comments within the XML DTD. The comments should include the public identifier for invocation of the XML DTD.

Accepted.

2. The relationship between the elements/attributes of the XML DTD and those defined in the main body of ISO/IEC 13250 should be described.

Accepted. There is no one-to-one correspondence between the element types defined in the ISO/IEC 13250:2000 meta-DTD and the element types defined in the XTM 1.0 DTD. The exact mapping will be provided when there is a rigorous common substrate for both syntaxes -- the layered data model now under discussion.

3. Remove the clauses of "Defect Report on Topic Maps (ISO/IEC 13250:2000)".

Accepted.

4. Add the corrections in SC34 N238 and N239.

N 238:

(1) 2. Normative references, ISO 8879 Corrigendum 3 of ISO 8879:1986 should be removed. It is not published.

(2) 2. Normative references, ISO/IEC 10744 Amendment 1 of ISO/IEC 10744:1997 should be removed. It is not published.

(3) 4. Notation, para.4 "Copyrigyt(C)1999 International Organization ..." should be "Copyrigyt(C)2000 International Organization ..." "... defined in ISO/IEC 13250:1999, ..." should be "... defined in ISO/IEC 13250:2000, ..."

(4) B Annex B "... ISO/IEC 13250:1999 ..." should be "... ISO/IEC 13250:2000 ..."

(5) A Annex A, p.31 "<!attlist topicmap" is not closed by ">".

(6) A Annex A, p.32 "<!attlist topic" is not closed by ">".

Please see N239.

Norway

The relationship between the existing DTD and this new one should be defined in normative text, and this normative text needs to be published and finalized as soon as possible. This normative text should take the form of a formal model, with directions on how to build instances of the model from SGML and XML documents.

Work has already started within the ISO SC34 working group to define the relationship between the two DTDs. Proposals for an underlying layered data model are currently under study. It may take time to develop the layered model to achieve consensus on it. In the meantime, it is important not to stall the development of the Topic Maps industry. The proposed incorporation of the XTM 1.0 DTD in the ISO standard is an important step forward. The editors recognize that simple incorporation of the XTM DTD cannot be considered the final step in the process of accommodating the needs of the Topic Maps industry. The forthcoming technical corrigendum need not be delayed until the elaboration of the layered model has been completed. The technical corrigendum can be limited to a few typographical corrections and the incorporation of the XTM 1.0 DTD. This will allow the development of the industry and the development of the layered model to be pursued in parallel.

Annex C:

the copyright statement in the DTD needs to have '' added around it the names of the authors should be added to the comment as a matter of courtesy the following paragraph should be added to the comment:

We're not able to understand this comment fully, but it appears to contradict a comment from the UK that we can't include copyright notices other than ISO's. We need to work to achieve consensus on this point. An alternative that can be discussed is to acknowledge the companies that were actively involved in the work of the authoring group and were named in the public announcement at the XML 2000 conference: ADIS International, Boeing, CCH, Cogitech, Inc., Crane Softwrights Ltd., Diffuse Project, EComXML, EMC, Empolis, Epremis Corporation, GlobalWisdom, Inc., Herrick Douglass, InfoLoom, Inc., Isogen/DataChannel, Laboratoire d'Informatique de Paris 6, McKinsey & Company, Minciu Sodas, Mondeca, NEC, Ontopia, RivCom, Shell Services International, Society of Biblical Literature, Sun Microsystems, The Bureau of National Affairs, Versaware, VerticalNet Solutions, Wrox Press, Y-12 National Security Complex.

"A provisional explication of this DTD can be found at http://www.topicmaps.org/xtm/1.0/"

Accepted.

United Kingdom

The UK approves this proposed Technical Corrigendum but asks the Project Editor to take note of the following comments.

1. The UK appreciates the substantial work done in developing the XTM 1.0 DTD but considers that the DTD should be included in a non-normative annex. The UK considers that there are several possible ways of representing topic maps in XML and the inclusion of the XTM 1.0 DTD should not constrain the use of the standard such that it creates problems for alternative implementations. The UK considers that any unreasonable constraints can be avoided by making the annex non-normative and changing any imperative requirements to recommendations by replacing occurrences of the word ‘must’ to ‘should’.

This is a delicate issue that requires a carefully-balanced solution. On the one hand, if the XTM DTD is not incorporated as normative text, then it cannot be claimed that it is "ISO standard", and the relationship between the ISO and the industry that is developing around the XTM DTD will be suboptimal, at best. On the other hand, we know of no one who desires to create a situation in which the ISO states that in certain objective situations (for example, in Web-based XML contexts), the XTM DTD must always be used to represent all information that might ever be regarded as Topic Map Information. Such a constraint would guarantee that no ISO seal of approval could ever be applied to situations in which the topic maps paradigm is used to amalgamate knowledge, when some of that knowledge may not have been interchanged in XTM form (or, for that matter, in the form of the HyTime-based 13250 meta-DTD, or in any other standard form). We are seeking a middle way, here, in which both syntaxes can be regarded as both normative and optional.
Any inconsistency resulting from the fact that we have multiple interchange syntaxes will only serve to make the underlying layered model more robust, and ultimately to make that model the primary arbiter of conformance. Therefore, we believe the approach of incorporating the XTM DTD now, and then later providing a layered model that shows how both syntaxes are viable and consistent with each others' intent, is in the best interests of both the industry and the public.

2. Text included in ISO standards cannot include third-party copyright statements.

Remove "Copyright 2000-2001 TopicMaps.Org. All rights reserved."

This contradicts Norway's comment. We must work to achieve consensus on this issue.

The following comments are offered as possible improvements to the DTD:

3. The proposed [XTM 1.0] DTD does not allow the expression of all functionality of ISO/IEC 13250. It should be possible to record facets at the very least.

Rejected. We are unaware of any kind of information that can be expressed in the HyTime-based meta-DTD syntax, but that cannot also be expressed in the XTM 1.0 DTD syntax. For example, a superset of the same information set that is expressible using the <facet> syntax can be expressed in XTM by associating non-addressable subjects with addressable subjects.

4. The proposed DTD provides features that are not part of ISO/IEC 13250. The following are additional to the requirements of the standard and should be identified as such. mergeMap, instanceOf, subjectIndicator and subjectIndicatorRef

Rejected. The semantics of <mergeMap>, <instanceOf>, <subjectIndicator> and <subjectIndicatorRef> are all expressible using the HyTime-based meta-DTD. It is true that the "<resourceRef>" element provides more powerful access to the "addressable subject" semantic, which is less powerfully/generally available in the <facet> syntax provided in the HyTime-based meta-DTD.

5. The proposed DTD does not distinguish variants used as sort names from variants used as alternative display versions.

Rejected. The <variant> mechanism is a generalization of the mechanism provided by <displayName> and <sortName>. An unbounded number of distinctions, including but not limited to the distinction between display names and sort names, are supportable using the XTM syntax. The specific semantics of "display-ness" and "sort-ness" are provided by standardized published subjects, and these published subjects can be used to guarantee the identicality of these concepts as they are referenced in instances of the two syntaxes.

United States

Normative text needs to be added to explain the relationship between the XTM DTD and the original HyTime architectural form meta-DTD.

Accepted. There are three things we would like to say in response to this comment:
  1. The formal, complete relationship between these two alternate syntaxes will fall out of the layered model development work (please see the above response to the comments from Norway). Normative text that will constrain and harmonize the processes of parsing both syntaxes will be added that will use the layered model as a kind of Rosetta Stone.
  2. We believe it would be best to make both syntaxes normatively optional (please see the above responses to the comments from the United Kingdom).
  3. We also propose to include informative text along the lines of the following survey of the differences between the two syntaxes:

    Introduction

    The ISO/IEC 13250:2000 "Topic Maps" International Standard has two interchange syntaxes, the HyTime-based meta-DTD, and the XTM DTD. The following is a survey of the relationships and differences between these two syntaxes.

    Describing the semantics of both syntaxes

    One of the purposes of the layered model of Topic Maps Information is to provide a means of describing the semantics of such information, in general, regardless of the representations that may be used to interchange it. The layered model also can be used to show how each different syntax (or other representation) can be used to interchange or store Topic Map Information, and to compare the ways in which each syntax reflects the inherent character of the underlying model of Topic Map Information. In order to rigorously define and constrain the interpretation of each syntax, it is desirable to describe how instances of each syntax can be transformed into instances of the common underlying model, and how instances of the underlying model can be transformed into instances of each syntax.

    It is important to recognize that information that has the character of Topic Map Information is ordinarily expressed in many different notations. It is highly desirable to be able to federate all kinds of "finding information", not just the finding information that happens to be expressed in one of only two syntaxes. The underlying layered model of Topic Map Information is applicable to any number of notations, although the ISO 13250 standard uses it only to constrain the interpretation of only two syntaxes -- the syntaxes that it happens to provide. Conformance to the underlying layered model will enable topic map applications to become omnivorous with respect to syntax.

    The difference between topic map syntax and topic map information

    If we consider a topic map abstractly, apart from the data used to represent it, its structure cannot be the same as any conceivable syntactic structures that could be used to interchange it. Neither HyTime-based nor XTM-based topic map documents are "ready-to-use" by application-specific logic. Before a topic map software application can be expected to perform its application-specific functions, generic parsing -- processing that must be performed in order to understand the topic map that an interchangeable instance of that topic map is designed to represent -- is required to make the topic map "ready-to-use".

    From an economic standpoint, there are significant advantages in using a distinct software module that implements this generic processing, commonly called a "topic map engine" or a "topic map parser". (The term "topic map parsing" means "all of the aspects of topic map processing that are required to be done by all topic map software that takes, as input, interchangeable topic maps that conform to any representation used for interchange or storage." The term "topic map processing" is much more generic; it refers to any kind of information processing that involves Topic Map Information, including both topic map parsing (as just defined) and application-specific processing of ready-to-use topic maps.

    Differences between the HyTime-based Topic Maps meta-DTD found in ISO 13250:2000 and the XTM 1.0 DTD

    Addressing

    Addressing in XTM is limited to Uniform Resource Indicators (URI) while addressing in the HyTime-based syntax can be expressed with virtually any kind of notation.

    Architectural forms versus fixed DTDs

    The HyTime-based meta-DTD is a set of architectural forms, or element type templates, rather than a set of element type definitions (the normal kind of DTD). An architectural form constrains conforming interchange syntaxes in such a way that instances can always be understood by receiving systems just as if they were direct instances of the meta-DTD. However, the instance need not use the same element type names used in the architectural form definitions, and many other variations are also possible. DTD designers can conform to the meta-DTD and yet, at the same time, create their own element types that inherit the processing and consistency constraints imposed by the meta-DTD.

    Even though the ISO standards from which they were derived enjoy the flexibility and other benefits of architectural forms, the W3C family of XML standards does not use or support the architectural form paradigm. Accordingly, the XTM DTD has a fixed set of element types and attributes. This facilitates topic map interchange using XML-based technologies.

    The XTM DTD prefers element types to attributes

    The XTM DTD uses elements, wherever possible, rather than attributes. This design choice was made possible because the number of primitives in XTM is very small and was motivated by making the syntax easy to read. As a consequence, the XTM syntax is more verbose than HyTime-based meta-DTD. HyTime-based DTDs generally prefer attributes, and the HyTime-based meta-DTD for Topic Map interchange is no exception.

    The XTM DTD generalizes "display name" / "sort name" as "variant name"

    The HyTime-based meta-DTD has a provision to add to each name a variant form for display and another for sort keys. This mechanism has been expanded in the XTM DTD and is now available as a generic method to add variant names to topics for any processing context by defining parameters that describe and/or identify that processing context. Display and sort are in the XTM syntax only two specific cases of this feature and are referenced as published subjects. Also, variant names can be organized into hierarchies.

    The HyTime-based meta-DTD uses HyTime varlinks, while the XTM DTD uses "simple" Xlinks

    The XTM DTD boosts the notion of subject constituting resources to fully equal status with subject indicating resources. Both kinds of subjects (addressable subjects and non-addressable subjects) can participate equally easily in every construct involving a topic. In the present version of the HyTime-based meta-DTD, only subject-indicating resources can be used to declare the subjects of topics.

    Types of referencing elements in the XTM DTD.

    The XTM syntax contains a mechanism to express explicitly the nature of the information being referenced: If it's the subject of a <topic>, then it is referenced using a <topicRef> element. If it's a resource constituting a subject, it is referenced using a <resourceRef> element. If it is a resource indicating a subject, it is referenced using a <subjectIndicatorRef> element.

    Facets are not mentioned in the XTM DTD.

    In the HyTime-based meta-DTD, facets are qualifiers used to assign a property (and a value for the property) to an information object. Facets are not needed in the XTM DTD because the XTM DTD allows a topic map author to explicitly regard an information object as a subject in itself (a subject constituting resource). In the XTM DTD, therefore, it is possible to associate properties and values with information objects by means of <association> elements.

    "Public subject" renamed "published subject"

    What is called "public subject" in 13250:2000 is called "published subject" in XTM 1.0. This new name is less reflective of SGML jargon, but more in keeping with the meaning of the term, considering the normal semantics of the English language.