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]                                   

Summary of Voting on SC 34 N 9, ISO/IEC CD 13250, Information Technology - Topic Navigation Maps

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)

Brazil, China, Ireland

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.

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.

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.

The "data attribute" should be explained more clearly.

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".

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."

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

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.

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

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

Avoid the following identical wordings not to cause a confusion:

• 4.15 Scope
• 2 Scope

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.

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.

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.