ISO/IEC JTC 1/SC 34
Document Description and Processing Languages
ISO/IEC JTC 1/SC34 N 44
DATE: 1999-03-08
REPLACES
DOC TYPE:
Summary of Voting/Table of Replies
TITLE:
Summary of Voting on SC 34 N 9, ISO/IEC 13250, Information Technology
- Topic Navigation Maps
SOURCE:
Secretariat, ISO/IEC JTC 1/SC 34
PROJECT: 1.34.67
STATUS:
To JTC 1/SC 34 for information and to WG 3 for preparation of a
disposition of comments report and recommendation on further
progression of the work.
ACTION ID: FYI
DUE DATE:
DISTRIBUTION: P and L Members
SC Chairman
WG Conveners and Secretariats
MEDIUM: E
DISKETTE NO.:
NO. OF PAGES: 48
ISO/IEC JTC 1/SC 34, American National Standards Institute, 11 West
42nd Street, New York, NY 10036, Tel: +1 212 642 4976, Fax: +1 212
840 2298, Email: [email protected]
ISO/IEC JTC 1/SC 34 N 44
Summary of Voting on SC 34 N 9, ISO/IEC CD 13250, Information Technology - Topic Navigation Maps
SC 34 National Body P-Members (13)
Australia, Brazil, Canada, China, Denmark, France, Ireland, Italy, Japan, Netherlands, Norway, United Kingdom, United States
P-Members in Favour (10 of 15)
Australia, Canada, Denmark, France (w/comments), Italy, Japan (w/comments), Netherlands, Norway (w/comments), United Kingdom (w/comments), United States (w/comments)
P-Members Voting Against (0 of 15)
P-Members Abstaining (0 of 15)
P-Members who did not vote (3 of 15)
Brazil, China, Ireland
FRANCE
YES with comments.
---------------------------------------
The comments are below :
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.
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.
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 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.
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.
6. There should be a note explaining that occurrences and public topic
definitions can be offline resources.
7. The "occur" element type should be called "occurs" because of its
inherently plural character.
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?
9. In view of the semantics of "fullname", its name should be changed
to "basename".
10. Definitions for "fullname" (or "basename") and "display name"
should be 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.
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.
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.
14. The role of generic identifiers and type attributes in specifying
topic types, etc. should be explained more clearly.
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.
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".
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.
18. The (redundant) HyDoc declaration should be removed from the topic
map meta-DTD in Annex A.
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".
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.)
21. Lower case should be used for terms in the definitions clause.
22. The term "topic characteristic" should be defined in the
definitions clause, and the definition should explain exactly how
a characteristic becomes a characteristic.
23. The term "topic association" should be defined in the definitions
clause.
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."
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.
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.
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.
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.
JAPAN
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:
(1) Topic Map
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.
(2) 3 Normative references
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.
(3) 4.1 Added scoping topics
The "data attribute" should be explained more clearly.
(4) this Standard
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".
(5) 6.2.1 Public Association Type References, para 2
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."
(6) Annex B
ISO/IEC JTC 1/SC 34/N1957 should be ISO/IEC JTC 1/WG 4 N 1957.
(7) NOTE
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.
(8) Notation Clause
There should be a Notation Clause, which clarifies the meanings of:
- Italic expression
- the expression by fixed-pitch fonts
- quotation marked expression
(9) Identical Wordings
Avoid the following identical wordings not to cause a confusion:
- 4.15 Scope
- 2 Scope
NORWAY
Comments from the Norwegian National Body on ISO/IEC CD 13250 ("Topic Navigation Maps")
Norway votes "Yes with comments" to CD 13250. The comments are as follows:
1. The name of the standard
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.
2. Clarifying fundamental concepts
(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".
(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.
(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".
(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.
(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.
3. Regarding topic names
(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?
(b) In view of the semantics of "fullname", its name should be changed to "basename".
(c) Definitions for "fullname" (or "basename") and "display name" should be 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.
(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.
(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.
4. Minor editorial comments
(a) Names used for constructs in the meta-DTD should be made more consistent. Either all names should be within the limits of the RCS (in which case some will necessarily be cryptic), or else they should all be recognizable from the full name of the construct.
(b) The "occur" element type should be called "occurs" because of its inherently plural character.
(c) Inconsistencies such as "occrole/assocrl" should be resolved. (In this case, either to "occrole/assrole" or "occurrl/assocrl".)
(d) Lower case should be used for terms in the definitions clause.
(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.
UNITED KINGDOM
UK comments on ISO/IEC FCD 13250- Information technology – Topic Navigation Maps (SC34 N009)
The UK APPROVES the text with the following comments.
Comments
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.
1.Copyright
The Copyright Notice that is contained on page 1 of the HTML version of the FCD text (sourced from the SC 34 Secretariat) is unacceptable in an International Standard published by ISO.
2.Change control of definitive text
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.
Any online publication of this standard must ensure that all links point to only one definitive source that is maintained under the control of ISO ITTF.
UNITED STATES
Proposed U.S. National Body Comments on
FCD ISO/IEC 13250, Topic Navigation Maps
(SC 34 N 009)
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.
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.
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.
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.
7. There should be a note explaining that occurrences and public topic
definitions can be offline resources.
8. The "occur" element type should be called "occurs" because of its
inherently plural character.
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?
10. In view of the semantics of "fullname", its name should be changed
to "basename".
11. Definitions for "fullname" (or "basename") and "display name"
should be 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.
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.
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.
16. The role of generic identifiers and type attributes in specifying
topic types, etc. should be explained more clearly.
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".
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.
21. The (redundant) HyDoc declaration should be removed from the topic
map meta-DTD in Annex A.
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".
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.
25. The term "topic characteristic" should be defined in the
definitions clause, and the definition should explain exactly how
a characteristic becomes a characteristic.
26. The term "topic association" should be defined in the definitions
clause.
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."
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.
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.
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.
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.