---

P-Member	APPROVAL OF THE DRAFT AS PRESENTED	APPROVAL OF THE DRAFT WITH COMMENTS AS GIVEN ON THE ATTACHED	DISAPPROVAL OF THE DRAFT FOR REASONS ON THE ATTACHED	DISAPPROVAL (appropriate changes in the text will change vote to APPROVAL)	ABSTENTION (For Reasons Below)	NO RESPONSE
Canada	X
China						X
Italy	X
Japan		X
Korea	X
Netherlands	X
Norway		X
United Kingdom		X
United States		X

Japan

Technical comments

1. All part of the specification

   "URI"
   should be changed to
   "IRI",
   because an IRI is a sequence of characters from the
   Universal Character Set (Unicode/ISO 10646) and allows to use non-Latin scripts in it.  

2. Introduction, 1st paragraph, 1st sentence

   "XTM 1.1 is a syntax ... "
   should be
   "XTM (XML Topic Maps) 1.1 is a syntax ... ".

3. Clause 3. Terms and difinitions

   Term "XTM" should be added.

4. Clause 4.8 The variant element

   It is written as follows:
   "... and may also contain other variant names with scopes that are supersets of the scope ... ".
   The "scopes" and "scope" should be deleted, because of there is no scope element in the variant element.

5. Clause 5.9 The variantName element, 3rd paragraph

   There are two kinds of properties. Some of them come from TMDM, the others come from XML-infoset. But sometimes it is hard to distinguish which standard they come from. For example, from which "[children] property" and "[character code] property come. So it should be clearly described which standard they come from.

6. Annex E

   The following statement should be added:

   The "resourceData" element now has a new "datatype" attribute.
   The "resourceData" element now has a new "any-markup".


Editorial comments

1. Clause 2. Normative references

   "ISO 13250-2, Topic Maps - Data Model, ... "
   should be
   "ISO/IEC 13250-2, Topic Maps - Data Model, ... ".

2. Clause 2. Normative references

   "W3C XML, Extensible Markup Language (XML) 1.0 (Second Edition), ... "
   should be
   "W3C XML, Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation, 4th February 2004, available at <http://www.w3.org/TR/2004/REC-xml-20040204/>".

3. Clause 2. Normative references

   "ISO 19757-2, ... "
   should be
   "ISO/IEC 19757-2, ... ".

4. Clause 2. Normative references

   "IETF RFC 2396, ... "
   should be changed to
   "IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax ... , January 2005, available at <http://www.ietf.org/rfc/rfc3986.txt>".

5. Clause 2. Normative references

   "IETF RFC 2732, ... "
   should be deleted, because of it is included in IETF RFC 3986.

6. Clause 2. Normative references

   "IETF RFC 3987, Internationalized Resource Identifiers (IRIs), Internet Standards Track Specification, January 2005, available at <http://www.ietf.org/rfc/rfc3987.txt>" should be added.

7. Clause 2. Normative references

   "XTM1.0, XML Topic Maps (XTM) 1.0 Specification, ... "
   should be moved to Bibliography.

8. Clause 4.16 The member element

   "The member element type is used to add one or association roles of ..."
   should be
   "The member element type is used to add one or more association roles of ...".

9. Clause 5.15 The member element, 2nd paragraph

   "[players] property"
   should be
   "[player] property".

Norway

1	2	(3)	4	5	(6)	(7)
MB1	Clause No./ Subclause No./ Annex (e.g. 3.1)	Paragraph/ Figure/Table/Note (e.g. Table 1)	Type of com-ment2	Comment (justification for change) by the MB	Proposed change by the MB	Secretariat observations on each comment submitted

NO	4.4		te	Requiring an id attribute on <topic> elements is unnecessary and leads to problems. If the topic has a subject identifier or locator this can (and should) be used to refer to it, and so in these cases the id is not needed. Not requiring the id will encourage the use of PSIs, which is the preferred alternative. Requiring the id leads to problems when topic maps are maintained in persistent stores over a long time and updated by regular imports during which duplicated ids may lead to undesired merging.	Make the id attribute on <topic> optional. Modify the RELAX-NG schema so that <topic> elements must either have an id or have a <subjectIdentity> element with content.
NO	4.8		te	The nesting of <variant> elements is not explained.	Add a NOTE to make it clear that nesting of variants is just a syntactical shorthand, and not really recommended as a good practice.
NO	4.12		te	In <topic><instanceOf id="x"/> the id should turn into a source locator on the association item created in the TMDM representation. This avoids throwing away an identifier, and also makes it possible to use <instanceOf> even when the association is being reified.
NO	5.15		te	The rule that topics are auto-generated in <member> when the player is not specified should be revisited. Either a convention for auto-generating a source locator for such topics should be defined, or else the requirement that all topics have a URI identity should be removed.

United Kingdom

1	2	(3)	4	5	(6)	(7)
MB1	Clause No./ Subclause No./ Annex (e.g. 3.1)	Paragraph/ Figure/Table/Note (e.g. Table 1)	Type of com-ment2	Comment (justification for change) by the MB	Proposed change by the MB	Secretariat observations on each comment submitted

GB	Clause 4.1.4		Ed	Datatype attribute should be defined as string in relation to comment made on [datatype] property.
GB	Clause 4.8		Ed	Content model should read: {id?, parameters, (variantName, variant*) | variant +} or deserialization in 5.8/5.9 needs to specify a default variantName value.
GB	Clause 4.16		Ed	Content model should read: {id?, roleSpec?, topic-reference+ }
GB	Clause 5.2.7		Ed	Canonicalization is applied to XML data when the datatype specifies the "XML" data type. If the datatype specifies a non-XML data type (e.g. string) but the content is XML markup, is this an error ?
GB	Clause 5.13		Ed	Rewrite first sentence of last paragraph as a separate para. Note that [datatype] property should be set to the value of the datatype *attribute* The deserialisation process does not allow markup in user-defined data types. Either allow markup in user-defined data types or restrict data typing to xml, uri and string and resolve user-defined data types through xml namespaces on the xml data type values. General Comment on all parts of ISO 13250 and related standards: All URIs referencing part of the standards should be clearly identified as being owned by ISO. Either they should be changed to the agreed ISO format for identifying standards or it should be made clear on the home page of www.topicmaps.org that the namespace is one that is registered as being owned by ISO SC34 members.

United States

1. Introduction: reads in part: "Other XML syntaxes that represent topic map information may well define mappings to the XTM syntax, however."

   Unnecessary as well as grammatically incorrect.

2. 3 Terms and definitions

   The definitions should be complete sentences with punctuation.

3. 4.1 General, second paragraph reads: The XTM syntax represents all references as simple XLinks conformant to the XLink specification [W3C XLink]. However, since the xlink:type attribute is not required XML documents can be valid XTM documents without being valid according to XLink. The inclusion of the xlink:type attribute on all XLink elements is encouraged for compatibility with XLink.

   But in sections 4.18 topicRef, 4.19 subjectIndicatorRef, 4.20 resourceRef, and 4.21 mergeMap, the xlink:href attributes are required to conform to XLink. Is there some advantage to not requiring the use of xlink:type?

4. 4.2 Common declarations

   The content model for any-markup is lacking any definition of the term "xtm." Without some definition of what is meant, the content model is meaningless.

5. 4.4 The topic element: "element type"

   The phrase "element type" is first used here and the repeated some 35 times in sections 4.4 - 4.21. The usage then switches to "element."

   "Type" is a defined term in RELAX-NG and it is both confusing and unnecessary to use "type" in section 4 at all.

6. 4.4 The topic element: "used to create"

   It is said that "The topic element type is used to create topics..."

   No, a topic element does not create topics.

   Suggest: The topic element acts as a container and point of reference for topic information.

7. 4.4 The topic element: topic element type is declared

   Suggest: The topic element is declared as follows:

   To avoid repetition, this comment applies to all following similar usages.

8. The baseName Element

   First sentence concludes: "...to the topic created by the parent topic element." Strike "created by" and say: "...to the parent topic element."

9. 4.8 The variant element

   First paragraph, first sentence reads: "The variant element type is used to create a variant name of a base name, and may also contain other variant names with scopes that are supersets of the scope of that of the containing variant name."

   First, strike the "to create a variant name...." Second, the variant name is not "of a base name" but a variant name for the topic element. Third, sorry, the last bit, "may also contain other variant names with scopes that are supersets of the scope of that of the containing variant name." simply doesn't make any sense. What containing variant name? The element under discussion is variant and not variant name.

10. 4.11 The scope element

    The first paragraph, first sentence reads: "The scope element type is used throughout XTM...."

    The "used throughout XTM" phrase also occurs in 4.12, 4.18, 4.19, and 4.20. The usage is inconsistent with the other parts of the section.

    Note that "XTM" is never defined in this draft, the closest being the definition of XTM document in 3.4.

11. 4.12-4.17, 4.21, used to...

    The phrase "used to" occurs in these sections as "used to assign, ...provide, ...express, ...add, ...specify, and ...refer. Seems it would be simplier to simply state the function of the element without attempting to have artistic variation in the text.

12. 4.12 The instanceOf element

    Second sentence reads: "The type is always a topic, indicated by the child element." Assume that means the instanceOf element but that is far from clear.

13. 4.16 The member element

    Currently reads: "The member element type is used to add one or *association roles of the same type* to the association created by the association parent element."

    Wrong. At least according to the definitions contained in the TMDM (13250-2). With those definitions inserted after the terms it reads:

    The member element type is used to add one or association roles [13250-2 3.3 "a representation of the involvement of a subject in a relationship representated by an association"] of the same type [13250-2 3.4 "a topic defining the nature of the participation of an association role player in an association"]to the association created by the association parent element.

    Literally says that an association is composed of sets of typing topic only.

    Suggest: The member element contains one or more association roles within an association element.

14. 4.16 The member element (last paragraph)

    Currently reads: "The id attribute is ignored when there is more than one topic reference child, but used to refer to the member element when there is one or zero such children."

    Three problems, first, when is the id attribute ignored and when is it used? Second, "topic reference" child should be "topic-reference" child to be consistent with the declaration in 4.2. Which is itself problematic in terms of producing a readable standard. Third, why is the id relevant at all, if as stated by 5.15, the member element has no direct impact on the information set but affects the processing of its descendant elements?

15. 5.1 General

    The last sentence of the first paragraph reads: "This part of ISO/IEC 13250 defines how to deserialize XTM documents in Clause 5, and serialization is implicitly defined."

    This is Clause 5 so the self-reference seems awkward. Note that serialization is the subject of 13250-4, should 13250-3 be taken as defining serialization as well?

16. 5.2.7 Canonicalizing embedded XML, first paragraph, first sentence reads: XTM documents may contain arbitrary markup inside resourceData elements, and this markup is represented in the data model as a string.

    The data model, 13250-2 has no reference mapable to resourceData elements.

17. 5.5 The subjectIdentity Element

    First sentence, "of the child element" should read "of its child elements."

18. 5.9 The variantName Element

    First sentence, "of its child element" should read "of its child elements." Note plural.

19. 5.15 The member element (first paragraph)

    Reads: "The member element does not have any direct impact on the information set being created, but affects the processing of its descendant elements."

    It is unclear how affecting "the processing of its descendant elements" does not qualify as having a "direct impact" on the information set.

    Suggest striking this paragraph. Simply state the rules.

20. 5.15 The member element (general comment)

    It would be easier to follow the prose if it followed the content model. Here it is inverted from the actual content model (as expanded).

21. 5.16 The topicRef element (first paragraph)

    Reads: "The topicRef element always produces a topic item, as described below. How the topic item is used depends on the context in which the topicRef element appears, and is described in the part of this document describing the processing of the topicRef element's parent element."

    This paragraph says that a topicRef is processed as stated below or as stated elsewhere. Is that necessary?

22. 5.16 The topicRef element (third paragraph)

    Reads: "After processing the reference, if the data model has a topic item whose [subject identifiers] or [source locators] properties contain a string equal to the one produced above that topic item is the one produced by this topicRef element."

    Sorry, have tried parsing that several ways and keep getting stuck on "the one produced above that topic item...." Simply don't know what is meant by this paragraph.

23. 5.17 The subjectIndicatorRef element (first paragraph)

    Reads: "The subjectIndicatorRef element produces a topic item, as described below. How the topic item is used depends on the context in which the subjectIndicatorRef element appears, and is described in the part of this document describing the processing of the subjectIndicatorRef element's parent element."

    Same problem as with the first paragraph of 5.16. If the processing is stated elsewhere, isn't that sufficient? Not merely a matter of style but stating something twice (or more) provides opportunities for conflicting interpretations. State whatever the processing rule is once and only once. Then refer to it from other sections.

24. 5.17 The subjectIndicatorRef element (second paragraph)

    Same comment as noted for 5.16 on the "above that topic item" language. Simply don't know what is meant.

25. 5.18 The resourceRef element (first paragraph)

    Same comment as noted for 5.16 and 5.17. Unnecessary and may lead to conflicting interpretations.

26. 5.18 The resourceRef element (second paragraph)

    Same comment as noted for 5.16 on the "above that topic item" language. Simply don't know what is meant.

27. 5.19 The mergeMap element (second paragraph)

    Reads in part: "If the information resource referred to by the given URI has already been processed with an equal added scope nothing further is done. If it has not a data model instance is produced as described in 5.2.5. ..."

    It is not clear if the second sentence is meant to modify the first sentence. Actually it is not clear what the second sentence is trying to say.

28. Correspondence of Annexes A, B and C

    1. subjectIdentity

       In Relax, content model reads: "( resourceRef | topicRef | subjectIndicatorRef )*", while in the DTD, it reads: "( topicRef | resourceRef | subjectIndicatorRef )*" and in the XML Schema it reads: <xs:element ref="resourceRef"/> <xs:element ref="topicRef"/> <xs:element ref="subjectIndicatorRef"/>

       The content models should be in the same order, even for the informative versions.

    2. Other Examples of attribute order:

       The attribute order on topicRef, subjectIndicatorRef, resourceRef and mergeMap, are different between the RELAX-NG Schema and the DTD and XML Schema versions.

       To facilitate comparison, attributes should be listed in the same order.

    3. resourceData

       The content model for the RELAX-NG and XML Schemas allow any markup to occur in this element. The DTD for 1.1 allows only PCDATA.

       Suggest either dropping the any markup from the schemas or, dropping the DTD. Inconsistent markup models are not helpful.

29. Annex E:

    There is no mention in Annex E of the change of the content model of resourceData from PCDATA to any markup.