ISO/IEC JTC 1/SC34 N0057

Australia, Brazil, Canada, China, Denmark, France, Ireland, Italy, Japan, Netherlands, Norway, United Kingdom, United States

Australia, Canada, Denmark, France (w/comments), Italy, Japan (w/comments), Netherlands, Norway (w/comments), United Kingdom (w/comments), United States (w/comments)

1. In all of its statements of definitions, normative constraints,

etc., the standard should clarify whether the given statement

applies to the interchangeable form of topic map documents, or to

the abstract notions on which the standard is based, or to the

application-internal form of topic maps as created by applications

that process one or more topic map documents.

Accepted. A distinction has been made between "topic link" and "topic node" throughout the standard.

2. The concept of scope, which is fundamental to this standard and yet

challenging for some readers to grasp, needs to be discussed more

fully, perhaps in a note or in an informative annex.

Accepted. The definition of scope has been expanded with additional explanatory text. In addition, for clarification purposes, "scoping topic" has been renamed "theme".

3. "Public topics" are probably misnamed; they are not obviously

"public" in any ordinary sense of the word, and they are not

obviously "topics" in the same sense in which that word is used

elsewhere in this standard. This concept should be re-named in

such a way as to be more descriptive of what a "public topic"

really is, or, at the least, the term "public topic" should be

defined in such a way that the thinking behind the name is

revealed. The name of "public" attribute of the topic link form

should be changed to "identity" or "subject", and its referent(s)

should be termed something like "subject descriptor(s)" or

"identity definition(s)". The semantics of this re-named "public"

attribute must be defined in the standard in such a way that it is

clear that its referent must always be a definition of the subject,

and never the subject itself; otherwise, the semantics are

ambiguous.

Accepted. Public topics have been renamed "public subjects". the name of the "public" attribute has been changed to "identity". The concept of "public subject" has been clarified. The term "subject descriptor" is defined and used.

4. There is no need to make special arrangements for addressing any of

the concepts defined by the standard, just as there is no need for

authoritative definitions of other so-called "public topics" to be

provided with special facilities for addressing them, before they

can be used to define public topics. Therefore, the existing

section that defines certain public topics (OCCROLE, etc.) should

be deleted. Instead, the topics needed for topic map housekeeping

(OCCROLE, etc.) should be intrinsic to (and presumed to be

implicitly present in) all topic maps. Therefore, the "public

topics" defined in the draft should be topic nodes intrinsic to all

application-internal representations of topic maps. In that form,

perhaps they should be called something like "built-in topics" or

"topic map housekeeping topics". A normative annex should

enumerate and define these topics. This change will make it

possible to eliminate all of the draft's confusing language about

"implicit scope", too.

Accepted. There is now a distinction between "public subjects" and the topics that must be built into every application-internal representation of a topic map. The built-in topics are now defined separately. The enumeration of the built-in topics has been made part of the standard. The term "implicit scope" has been dropped.

5. The means whereby the definitions of public topics should be

addressed must not be limited to public identifiers. Limiting

public topics to "concept[s] identified by means of a formal public

identifier" is unjustifiable. The locations of definitions of

public topics should be specifiable by any combination of

syntactical devices, just as are the locations of occurrences.

Accepted. The location of public subject descriptors can be expressed in any notation.

6. There should be a note explaining that occurrences and public topic

definitions can be offline resources.

Accepted.

7. The "occur" element type should be called "occurs" because of its

inherently plural character.

Accepted.

8. The standard must clarify what is meant by "topic name" in various

contexts. Is it a fullname, a display name, a sort key name, or

all of them?

Accepted. A paragraph has been added explaining that topic names include all the names that can be found in a topic name element.

9. In view of the semantics of "fullname", its name should be changed

to "basename".

Accepted.

10. Definitions for "fullname" (or "basename") and "display name"

should be added.

Accepted. Definitions have been added.

11. A dispname should be allowed to be a graphic (with required

alternative text), but neither fullname nor sortkey should be

anything but text. It should be clarified that the alternative

text is the entry used in the namespace defined by the scope

specified for the containing name element.

Accepted. Dispname can be any notation data as well as text. This accounts for the possibility that the dispname might be a sound, a smell, or other multimedia experience.

12. Either fullname should not be required (recognizing that the only

purpose of a name element is to specify scope), or, if there is

some other reason to group dispnames and sortnames together with a

single required fullname in each name element, that reason should

be spelled out in the standard. Also, the reason for having only

one fullname is not explained; either fullname should be optional

and repeatable or the reason for not making it optional and

repeatable should be spelled out.

Accepted in principle. Text has been added explaining that the reason why basenames, display names and sort key names may share a single containing name element is to allow them to share a single scope specification. The content model of the name element has been modified so that there can be any number of basename, dispname, and sortname elements as long as there is at least one basename. The standard now explains that the reason at least one basename is required is that there must be at least one name that can be used in the namespace defined by the scope.

13. The ordering constraint that requires name elements to precede

occurs elements in the content of topic link elements is

unnecessary. At least in SGML documents (but not in XML

documents), a content model that allows these elements to appear

in any order would work equally well and it would offer easier

retrofitting of existing link sets.

Accepted. The content model of topic link has become an optional and repeatable group.

14. The role of generic identifiers and type attributes in specifying

topic types, etc. should be explained more clearly.

Accepted. Every effort has been made to clarify when generic identifiers are regarded as having been overridden by type attributes.

15. The word "Navigation" in "Topic Navigation Maps" is redundant; the

"Map" metaphor strongly implies navigation. Also, "Navigation"

implies a narrower scope than this standard has, as if the

applications of topic maps necessarily always involve some sort of

navigation. "Navigation" should be dropped from the name of this

standard.

Accepted. The word "navigation" has been dropped. The standard is now called "Topic Maps". A side effect has been that the exemplary declaration of the topic map architecture has been altered so that the architectural form name attribute's name is "TopicMap" instead of "TNM".

16. In the draft, the term "topic" is used in several senses, and it

is not always clear which sense(s) is/are applicable in any given

context. The standard should be edited in such a way as to

clarify which senses of the term apply to each use, or perhaps new

terms should be used for each of the senses, or some combination

of the two techniques should be used to make the standard much

clearer in this respect. Similarly, the topics that are described

by topic navigation maps may fulfill one or both of two distinct

roles: the role of "topic" and the role of "scoping topic". The

clarity of the standard would be enhanced by making this

distinction terminologically, perhaps by using the term "theme" in

place of "scoping topic".

Accepted. The term "topic" is now qualified in most of the contexts in which it appears. For example, "topic node" is distinct from "topic link". "Theme" has been adopted to distinguish topics used in scopes (formerly "scoping topics") from topics in all their other roles.

17. The "facet" architectural form may be useful outside the context

of topic navigation maps. If it is possible to disentangle its

semantics from those of topic navigation maps, create a distinct

facet architecture which can be used independently of the topic

map architecture.

Accepted in principle. There is no requirement that facets be used only in the context of the rest of the architectural forms in the topic map architecture. The Topic Map architecture can be applied in such a way that only the facet architectural form is ever used in a topic map document. Indeed, in a topic map architecture, topics, topic links, association links and facet links are all regarded as context-free content.

18. The (redundant) HyDoc declaration should be removed from the topic

map meta-DTD in Annex A.

Accepted in principle. The HyTime=HyDoc attribute definition remains in the topicmap element's attribute definition list for documentary reasons, as an aid to understanding. A comment has been added to the effect that this attribute definition is redundant.

19. Since it is merely an example, Annex B should be informative

rather than normative. For the sake of internal consistency, the

arcquant name length in the topic map architecture use declaration

should be "NAMELEN 12".

Accepted.

20. The need to have different meta-DTDs that conform to different

SGML declarations should be explained, particularly in order to

account for the special constraints imposed by XML syntax. (This

explanation could be made in such a way as to be reusable by all

architecture-defining standards.)

Accepted. A paragraph has been added at the beginning of annex A that explains that conformong meta-DTDs may differ from the meta-DTD provided in the standard in order to conform to the constraints imposed by alternative SGML declarations. The paragraph and its accompanying note could appear in any architecture definition document.

21. Lower case should be used for terms in the definitions clause.

Accepted.

22. The term "topic characteristic" should be defined in the

definitions clause, and the definition should explain exactly how

a characteristic becomes a characteristic.

Accepted. Both "topic characteristic" and "topic characteristic assignment" have been defined.

23. The term "topic association" should be defined in the definitions

clause.

Accepted.

24. The term "topic type" should have an additional alternative

definition: "The class of a topic as indicated by the type

attribute of a topic link."

Accepted.

25. The draft's common data atribute "added scoping topics" serves a

vital function which will be unavailable to XML applications, due

to XML's current lack of support for data attributes. The same

purpose can be served by means of a semantically equivalent

element form that will be useful in both SGML and XML contexts.

Accepted. The common data attribute has been dropped. The same functionality is now provided by the addthms architectural form. This functionality is available in both SGML and XML applications without difference.

26. The facilities for adding scoping topics to topic characteristics

are not completely generalized. In the draft, scoping topics can

be added to all the characteristics of all of the topic links in a

topic navigation map document, both from inside and from outside

the document. However,

* There is no ability to add scoping topics to all of the topic

characteristics of any arbitrary set of topics.

* There is no ability for a topic link to add scoping topics to

all of its own characteristics.

* There is no ability to add scoping topics to any arbitrary set

of topic characteristics.

Such facilities should be added.

Two points accepted, one rejected.

An attribute "topics" has been added to the "addthms" architectural form for adding themes to all of the scopes of all of the characteristics of any arbitrary set of topics.
A scope attribute has been added to the "topic" link architectural form that permits a topic link to add themes to all of its characteristics.
Ability to add scoping topics to any arbitrary set of topic characteristics is rejected. The value of this functionality is minimal while the complexity it would add to the interchange syntax is undesirable.

27. Because the addscopt attribute of the document element form

specifies, in some sense, the overall scope of the document

itself, this attribute's name should be more reflective of that

fact, e.g., "basetheme", "basescope", etc.

Accepted in principle. "addscopt" is now called "addthems". For consistency's sake, this name is the same name used for the attribute that has the same function in the "addthms" architectural form.

28. In order to avoid confusion, the distinction between the meaning

of the word "scope" in ISO jargon (as in "Scope clause") and in

topic navigation map jargon should be carefully elucidated.

Accepted. A note has been added at the beginning of the scope clause and where the term "scope" is defined.

The National Body of Japan approved the Final Committee Draft of Topic Navigation Maps (ISO/IEC FCD 13250, SC 34 N 009) with the following comments:

The terminology "Topic Map" occurred in many clauses, e.g., 4.20, should be replaced with "Topic Navigation Map" or "TNM" to avoid a terminology confusion.

Accepted in principle. The word "navigation" has been dropped consistently, so the standard refers to itself consistently using the phrase "Topic Map".

The clause of "3 Normative references" should include:

SGML TC 3:1998

since "1 Introduction" refers to Annex K of WebSGML in the TC 3.

ISO/IEC 9070:1991

since "4.13 Public Topic" refers to the formal public identifier defined by ISO/IEC

9070.

Accepted. However, since public identifiers are no longer specifically referenced or required by the standard, all references to 9070 have been dropped.

The "data attribute" should be explained more clearly.

Accepted in principle. The data attribute has been dropped. The same functionality is now provided by the addthms architectural form, and the document of its function has been improved.

The wording "this Standard" occurred in many clauses, e.g., 6.1.2.7, 6.1.2.8, etc., should be replaced with "this International Standard".

Accepted.

The description

"In the above format specification, the registration indicator, public text class and language fields are as specified for formal public identifiers in ISO/IEC 8879:1986."

should be

"In the above format specification, the registration indicator, public text class and language fields are as specified for formal public identifiers in ISO 8879:1986 and ISO/IEC 9070:1991."

Accepted in principle. This text has been dropped because it is more longer relevant. References to public subject descriptors can be made in any notation, which may or may not involve formal public identifiers.

ISO/IEC JTC 1/SC 34/N1957 should be ISO/IEC JTC 1/WG 4 N 1957.

Accepted in principle. The sentence now reads: "The following example conforms to Annex A.3 of ISO/IEC 10744:1997, as amended via Amendment 1 in 1998."

In the PDF version, NOTEs are clearly specified. In the HTML version, however, there is no NOTE indication. Even in the HTML version, NOTEs should be specified.

Accepted.

There should be a Notation Clause, which clarifies the meanings of:

Italic expression
the expression by fixed-pitch fonts
quotation marked expression

A notation clause has been introduced into the standard.

Avoid the following identical wordings not to cause a confusion:

4.15 Scope
2 Scope

Accepted in principle. There is no way to avoid this conflict. In the one case, ISO rules demand that the title of the clause be "Scope". In the other case, we are defining the term "scope". However, a note has been added in both places.

Comments from the Norwegian National Body on ISO/IEC CD 13250 ("Topic Navigation Maps")

The word "Navigation" in "Topic Navigation Maps" is redundant; the "Map" metaphor strongly implies navigation. Also, "Navigation" implies a narrower scope than this standard has, as if the applications of topic maps necessarily always involve some sort of navigation. In fact, the topic paradigm can be seen as a fundamental principle for organising and maintaining information -- not just navigating it. "Navigation" should be dropped from the name of this standard.

(a) In the draft, the term "topic" is used in several senses, and it is not always clear which sense(s) is/are applicable in any given context. The standard should be edited in such a way as to clarify which senses of the term apply to each use, or perhaps new terms should be used for each of the senses, or some combination of the two techniques should be used to make the standard much clearer in this respect. Suggested terms are "subject" -- in place of the phrase "topic (in the generic sense of the word 'topic')", and "topic node" -- in place of the phrase "application-internal representation of the topic".

Accepted. The term "topic" is now qualified in most of the contexts in which it appears. For example, "topic node" is distinct from "topic link". "Theme" has been adopted to distinguish topics used in scopes ("scoping topics") from topics in all their other roles.

(b) Similarly, in all of its statements of definitions, normative constraints, etc., the standard should clarify whether the given statement applies to the interchangeable form of topic map documents, or to the abstract notions on which the standard is based, or to the application-internal form of topic maps as created by applications that process one or more topic map documents.

Accepted. A distinction has been made between "topic link" and "topic node" throughout the standard.

(c) Finally, the topics that are described by topic navigation maps may fulfill one or both of two distinct roles: the role of "topic" and the role of "scoping topic". The clarity of the standard would be enhanced by making this distinction terminologically, perhaps by using the term "theme" in place of "scoping topic".

Accepted.

(d) "Public topics" are probably misnamed; they are not obviously "public" in any ordinary sense of the word, and they are not obviously "topics" in the same sense in which that word is used elsewhere in this standard. This concept should be re-named in such a way as to be more descriptive of what a "public topic" really is, or, at the least, the term "public topic" should be defined in such a way that the thinking behind the name is revealed. The name of "public" attribute of the topic link form should be changed to "identity" or "subject", and its referent(s) should be termed something like "subject descriptor(s)" or "identity definition(s)". The semantics of this re-named "public" attribute must be defined in the standard in such a way that it is clear that its referent must always be a definition of the subject, and never the subject itself; otherwise, the semantics are ambiguous.

Public topics have been renamed "public subjects". the name of the "public" attribute has been changed to "identity". The concept of "public subject" has been clarified. The term "subject descriptor" is defined and used.

(e) The concept of scope, which is fundamental to this standard and yet challenging for some readers to grasp, needs to be discussed more fully, perhaps in a note or in an informative annex.

Accepted. The definition of scope has been expanded with additional explanatory text. In addition, for clarification purposes, "scoping topic" has been renamed "theme".

(a) The standard must clarify what is meant by "topic name" in various contexts. Is it a fullname, a display name, a sort key name, or all of them?

Accepted. A paragraph has been added explaining that topic names include everything that can be found in a topic name element.

(b) In view of the semantics of "fullname", its name should be changed to "basename".

Accepted.

Accepted. Definitions have been added.

(d) A dispname should be allowed to be a graphic (with required alternative text), but neither fullname nor sortkey should be anything but text. It should be clarified that the alternative text is the entry used in the namespace defined by the scope specified for the containing name element.

Accepted. Dispname can be any notation data as well as text. This accounts for the possibility that the dispname might be a sound or a smell.

(e) Either fullname should not be required (recognizing that the only purpose of a name element is to specify scope), or, if there is some other reason to group dispnames and sortnames together with a single required fullname in each name element, that reason should be spelled out in the standard. Also, the reason for having only one fullname is not explained; either fullname should be optional and repeatable or the reason for not making it optional and repeatable should be spelled out.

Accepted in principle. Text has been added explaining that the reason why basenames, display names and sort key names may share a single containing name element is to allow them to share a single scope specification. The content model of the name element has been modified so that there can be any number of basename, dispname, and sortname element as long as there is at least one basename. The standard now explains that the reason at least one basename is required is that there must be at least one name that can be used in the namespace defined by the scope.

(f) Topic map users may wish to define additional categories of topic names that do not fall into any of the three existing categories (fullname, dispname, sortname). One such category is acronyms. No set of categories can hope to be comprehensive, so there should be an additional name type that is explicitly undefined by this standard, which can be subtyped freely in applications, whenever the existing categories are not usable as supertypes.

Accepted in principle. Basename is already this "undefined" name type. Since basename is an architectural form, it can be subtyped in any way and any number of ways. The true significance of dispname and sortname is merely that if they are used, they appropriate the built-in themes of dispname and sortname respectively from any basenames that appear within the same containing name element.

(b) The "occur" element type should be called "occurs" because of its inherently plural character.

Accepted.

(d) Lower case should be used for terms in the definitions clause.

Accepted.

(e) In order to avoid confusion, the distinction between the meaning of the word "scope" in ISO jargon (as in "Scope clause") and in topic navigation map jargon should be carefully elucidated.

Accepted. A note has been added at the beginning of the scope clause and where the term scope is defined.

UK comments on ISO/IEC FCD 13250- Information technology – Topic Navigation Maps (SC34 N009)

The UK has no comments on the technical content of the draft standard however there are two issues of concern to the UK National Body that need resolution.

The UK National Body has concerns about the change control of the definitive text if this standard is published as an online interactive document. It has been possible to access source texts stored on different systems.

i.By accessing the URL (http://www.ornl.gov/sgml/sc34/document/0008.htm) identified on the notification of FCD ballot issued by the ITTF. ii.By accessing the text supplied by the SC34 Secretariat. Note that the text stored on the JTC1 file server should be the definitive text but the UK has had difficulty accessing it online. iii.The document supplied by the SC34 Secretariat contains links to another text stored at URL:<http://www.hightext.com/tnm/draft27.htm>

The above illustrates that there are currently at least three sources of the text. In the case of the links in the document provided by the SC 34 Secretariat, following a link actually changed the source server. This particularly worrying because it was not apparent for some time that the source of the text had changed.

1. In all of its statements of definitions, normative constraints,

etc., the standard should clarify whether the given statement

applies to the interchangeable form of topic map documents, or to

the abstract notions on which the standard is based, or to the

application-internal form of topic maps as created by applications

that process one or more topic map documents.

Accepted. A distinction has been made between "topic link" and "topic node" throughout the standard.

2. The concept of scope, which is fundamental to this standard and yet

challenging for some readers to grasp, needs to be discussed more

fully, perhaps in a note or in an informative annex.

Accepted. The definition of scope has been expanded with additional explanatory text. In addition, for clarification purposes, "scoping topic" has been renamed "theme".

3. "Public topics" are probably misnamed; they are not obviously

"public" in any ordinary sense of the word, and they are not

obviously "topics" in the same sense in which that word is used

elsewhere in this standard. This concept should be re-named in

such a way as to be more descriptive of what a "public topic"

really is, or, at the least, the term "public topic" should be

defined in such a way that the thinking behind the name is

revealed. The name of "public" attribute of the topic link form

should be changed to "identity" or "subject", and its referent(s)

should be termed something like "subject descriptor(s)" or

"identity definition(s)". The semantics of this re-named "public"

attribute must be defined in the standard in such a way that it is

clear that its referent must always be a definition of the subject,

and never the subject itself; otherwise, the semantics are

ambiguous.

4. There should be a note explaining that it's OK for occurrences to

be characterized as definitions (e.g., to have "definition" as

their occurrence role), but topic map applications will not

privilege such definitions in the same way that the referents of

the "public" attribute will be privileged.

5. There is no need to make special arrangements for addressing any of

the concepts defined by the standard, just as there is no need for

authoritative definitions of other so-called "public topics" to be

provided with special facilities for addressing them, before they

can be used to define public topics. Therefore, the existing

section that defines certain public topics (OCCROLE, etc.) should

be deleted. Instead, the topics needed for topic map housekeeping

(OCCROLE, etc.) should be intrinsic to (and presumed to be

implicitly present in) all topic maps. Therefore, the "public

topics" defined in the draft should be topic nodes intrinsic to all

application-internal representations of topic maps. In that form,

perhaps they should be called something like "built-in topics" or

"topic map housekeeping topics". A normative annex should

enumerate and define these topics. This change will make it

possible to eliminate all of the draft's confusing language about

"implicit scope", too.

Accepted. There is now a distinction between "public subjects" and the topics that must be built into every application-internal representation of a topic map. The built-in topics are now defined in a completely separate way. The enumeration of the built-in topics has been made part of the standard. The term "implicit scope" has been dropped.

6. The means whereby the definitions of public topics should be

addressed must not be limited to public identifiers. Limiting

public topics to "concept[s] identified by means of a formal public

identifier" is unjustifiable. The locations of definitions of

public topics should be specifiable by any combination of

syntactical devices, just as are the locations of occurrences.

Accepted. The location of public subject descriptors can be expressed in any notation.

7. There should be a note explaining that occurrences and public topic

definitions can be offline resources.

Accepted.

8. The "occur" element type should be called "occurs" because of its

inherently plural character.

Accepted.

9. The standard must clarify what is meant by "topic name" in various

contexts. Is it a fullname, a display name, a sort key name, or

all of them?

Accepted. A paragraph has been added explaining that topic names include everything that can be found in a topic name element.

10. In view of the semantics of "fullname", its name should be changed

to "basename".

Accepted.

11. Definitions for "fullname" (or "basename") and "display name"

should be added.

Accepted. Definitions have been added.

12. A dispname should be allowed to be a graphic (with required

alternative text), but neither fullname nor sortkey should be

anything but text. It should be clarified that the alternative

text is the entry used in the namespace defined by the scope

specified for the containing name element.

Accepted. Dispname can be any notation data as well as text. This accounts for the possibility that the dispname might be a sound or a smell.

13. Either fullname should not be required (recognizing that the only

purpose of a name element is to specify scope), or, if there is

some other reason to group dispnames and sortnames together with a

single required fullname in each name element, that reason should

be spelled out in the standard. Also, the reason for having only

one fullname is not explained; either fullname should be optional

and repeatable or the reason for not making it optional and

repeatable should be spelled out.

Accepted in principle. Text has been added explaining that the reason why basenames, display names and sort key names may share a single containing name element is to allow them to share a single scope specification. The content model of the name element has been modified so that there can be any number of basename, dispname, and sortname element as long as there is at least one basename. The standard now explains that the reason at least one basename is required is that there must be at least one name that can be used in the namespace defined by the scope.

14. Topic map users may wish to define additional categories of topic

names that do not fall into any of the three existing categories

(fullname, dispname, sortname). One such category is acronyms.

No set of categories can hope to be comprehensive, so there should

be an additional name type that is explicitly undefined by this

standard, which can be subtyped freely in applications, whenever

the existing categories are not usable as supertypes.

15. The ordering constraint that requires name elements to precede

occurs elements in the content of topic link elements is

unnecessary. At least in SGML documents (but not in XML

documents), a content model that allows these elements to appear

in any order would work equally well and it would offer easier

retrofitting of existing link sets.

Accepted. Content model of topic link has become an optional and repeatable group.

16. The role of generic identifiers and type attributes in specifying

topic types, etc. should be explained more clearly.

Accepted. Every effort has been made to clarify when generic identifiers are regarded as having been overridden by type attributes.

17. It is clear that topic maps may need to be merged into other topic

maps, but the merging concepts have not been adequately defined.

The nature of merging operations, the features of topic maps which

facilitate such merging, and the constraints imposed by the

standard on the merging process should be defined more clearly.

The roles played in the merging process by topic names, scopes,

and public topics should be clarified. The fact that the

underlying concepts of topic maps require that no two topics can

have exactly the same name in exactly the same scope must be

discussed more emphatically.

18. The word "Navigation" in "Topic Navigation Maps" is redundant; the

"Map" metaphor strongly implies navigation. Also, "Navigation"

implies a narrower scope than this standard has, as if the

applications of topic maps necessarily always involve some sort of

navigation. "Navigation" should be dropped from the name of this

standard.

19. In the draft, the term "topic" is used in several senses, and it

is not always clear which sense(s) is/are applicable in any given

context. The standard should be edited in such a way as to

clarify which senses of the term apply to each use, or perhaps new

terms should be used for each of the senses, or some combination

of the two techniques should be used to make the standard much

clearer in this respect. Similarly, the topics that are described

by topic navigation maps may fulfill one or both of two distinct

roles: the role of "topic" and the role of "scoping topic". The

clarity of the standard would be enhanced by making this

distinction terminologically, perhaps by using the term "theme" in

place of "scoping topic".

Accepted. The term "topic" is now qualified in most of the contexts in which it appears. For example, "topic node" is distinct from "topic link". "Theme" has been adopted to distinguish topics used in scopes ("scoping topics") from topics in all their other roles.

20. The "facet" architectural form may be useful outside the context

of topic navigation maps. If it is possible to disentangle its

semantics from those of topic navigation maps, create a distinct

facet architecture which can be used independently of the topic

map architecture.

Accepted in principle. There is no requirement that facets be used only in the context of the rest of the architectural forms in the topic map architecture. The Topic Map architecture can be applied in such a way that only the facet architectural form is ever used in a topic map document element. Indeed, in a topic map architecture, topics, topic links, association links and facet links are all regarded as context-free content.

21. The (redundant) HyDoc declaration should be removed from the topic

map meta-DTD in Annex A.

Accepted in principle, because the HyTime=HyDoc attribute definition remains in the topicmap attribute definition list for documentary reasons, as an aid to understanding. A comment has been added to the effect that this attribute definition is redundant.

22. Since it is merely an example, Annex B should be informative

rather than normative. For the sake of internal consistency, the

arcquant name length in the topic map architecture use declaration

should be "NAMELEN 12".

Accepted.

23. The need to have different meta-DTDs that conform to different

SGML declarations should be explained, particularly in order to

account for the special constraints imposed by XML syntax. (This

explanation could be made in such a way as to be reusable by all

architecture-defining standards.)

24. Lower case should be used for terms in the definitions clause.

Accepted.

25. The term "topic characteristic" should be defined in the

definitions clause, and the definition should explain exactly how

a characteristic becomes a characteristic.

Accepted.

26. The term "topic association" should be defined in the definitions

clause.

Accepted.

27. The term "topic type" should have an additional alternative

definition: "The class of a topic as indicated by the type

attribute of a topic link."

Accepted.

28. The draft's common data atribute "added scoping topics" serves a

vital function which will be unavailable to XML applications, due

to XML's current lack of support for data attributes. The same

purpose can be served by means of a semantically equivalent

element form that will be useful in both SGML and XML contexts.

Accepted. The functionality is now provided by the addthms architectural form. This functionality is available in both SGML and XML applications without difference.

29. The facilities for adding scoping topics to topic characteristics

are not completely generalized. In the draft, scoping topics can

be added to all the characteristics of all of the topic links in a

topic navigation map document, both from inside and from outside

the document. However,

* There is no ability to add scoping topics to all of the topic

characteristics of any arbitrary set of topics.

* There is no ability for a topic link to add scoping topics to

all of its own characteristics.

* There is no ability to add scoping topics to any arbitrary set

of topic characteristics.

Such facilities should be added.

Accepted.

An attribute "topics" has been added to the "addthms" architectural form for adding themes to all of the scopes of all of the characteristics of any arbitrary set of topics.
A scope attribute has been added to the "topic" link architectural form that permits a topic link to add themes to all of its characteristics.
Ability to add scoping topics to any arbitrary set of topic characteristics is rejected. The value of this functionality is minimal while the complexity it would add to the interchange syntax is undesirable.

30. Because the addscopt attribute of the document element form

specifies, in some sense, the overall scope of the document

itself, this attribute's name should be more reflective of that

fact, e.g., "basetheme", "basescope", etc.

Accepted in principle. "addscopt" is now called "addthems". For consistency's sake, this name is the same name used for the attribute that has the same function in the "addthms" architectural form.

31. In order to avoid confusion, the distinction between the meaning

of the word "scope" in ISO jargon (as in "Scope clause") and in

topic navigation map jargon should be carefully elucidated.

Accepted. A note has been added at the beginning of the scope clause and where the term scope is defined.

TITLE:	Disposition of Comments on Document SC34 N44, Summary of Voting, ISO/IEC CD 13250, Information Technology - Topic Navigation Maps
SOURCE:	ISO/IEC CD 13250 Editors
PROJECT:	JTC1.18.67
PROJECT EDITOR:	Michel Biezunski, Martin Bryan, Steve Newcomb
STATUS:	Approved Disposition of Comments
ACTION:	For information
DATE:	19 April 1999
DISTRIBUTION:	SC34 and Liaisons
REFER TO:	ISO/IEC JTC 1/SC 34 N 9, 44
REPLY TO:	Dr. James David Mason (ISO/IEC JTC1/SC34 Chaiman) Lockheed Martin Energy Systems Information Management Services 1060 Commerce Park, M.S. 6480 Oak Ridge, TN 37831-6480 U.S.A. Telephone: +1 423 574-6973 Facsimile: +1 423 574-0004 Network: masonjd@ornl.gov http://www.ornl.gov/sgml/wg4/ ftp://ftp.ornl.gov/pub/sgml/wg4/

ISO/IEC JTC 1/SC34 N0057

ISO/IEC JTC 1/SC34

Information Technology ---

Document Description and Processing Languages

Disposition of Comments on Document SC34 N44, Summary of Voting, ISO/IEC CD 13250, Information Technology - Topic Navigation Maps