ISO/IEC JTC 1/SC 34N0654

ISO/IEC logo

ISO/IEC JTC 1/SC 34

Information Technology --
Document Description and Processing Languages

TITLE: Disposition of comments on SC34 N0614: Topic Maps - Part 3: XML Syntax (XTM)
SOURCE: Mr. Lars Marius Garshol
PROJECT: FCD 13250-3: Information Technology - Topic Maps - XML Syntax
PROJECT EDITOR: Mr. Lars Marius Garshol; Mr. Graham Moore
STATUS: Agreed disposition of comments
ACTION: Editors to create FDIS ballot text
DATE: 2005-07-18
DISTRIBUTION: SC34 and Liaisons
REFER TO: N0614rev2 - 2005-07-12 - Summary of Voting on JTC 1/SC 34 N 589 - Information Technology - Topic Maps - XML Syntax
N0589b - 2005-01-14 - Ballot due 2005-05-14 - Information Technology - Topic Maps - XML Syntax
N0589 - 2005-01-14 - Information Technology - Topic Maps - XML Syntax
REPLY TO:

Dr. James David Mason
(ISO/IEC JTC 1/SC 34 Chairman)
Y-12 National Security Complex
Bldg. 9113, M.S. 8208
Oak Ridge, TN 37831-8208 U.S.A.
Telephone: +1 865 574-6973
Facsimile: +1 865 574-1896
Network: masonjd@y12.doe.gov
http://www.y12.doe.gov/sgml/sc34/
ftp://ftp.y12.doe.gov/pub/sgml/sc34/

Mr. G. Ken Holman
(ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada)
Crane Softwrights Ltd.
Box 266,
Kars, ON K0A-2E0 CANADA
Telephone: +1 613 489-0999
Facsimile: +1 613 489-0995
Network: jtc1sc34@scc.ca
http://www.jtc1sc34.org



Editors' disposition of comments on ISO 13250-3: XTM

Comments received during the XTM FCD ballot can be found in the Summary of Voting.

Comments from the Japanese National Body

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.

Accepted.

2. Introduction, 1st paragraph, 1st sentence "XTM 1.1 is a syntax ... " should be "XTM (XML Topic Maps) 1.1 is a syntax ... ".

Accepted.

3. Clause 3. Terms and definitions: Term "XTM" should be added.

Accepted.

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.

Rejected. The <parameters> element contains the scope of the variants.

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.

Accepted. Something will be done to make this clearer.

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

Accepted.

1. Clause 2. Normative references "ISO 13250-2, Topic Maps - Data Model, ... " should be "ISO/IEC 13250-2, Topic Maps - Data Model, ... ".

Accepted.

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

Accepted.

3. Clause 2. Normative references "ISO 19757-2, ... " should be "ISO/IEC 19757-2, ... ".

Accepted

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

Accepted

5. Clause 2. Normative references "IETF RFC 2732, ... " should be deleted, because of it is included in IETF RFC 3986.

Accepted.

6. Clause 2. Normative references "IETF RFC 3987, Internationalized Resource Identifiers (IRIs), Internet Standards Track Specification, January 2005, available at " should be added.

Accepted.

7. Clause 2. Normative references "XTM1.0, XML Topic Maps (XTM) 1.0 Specification, ... " should be moved to Bibliography.

Rejected. XTM 1.0 is referenced in normative text (clause 4.3), in a way that makes XTM 1.0 normative.

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

Accepted

9. Clause 5.15 The member element, 2nd paragraph "[players] property" should be "[player] property".

Accepted.

Comments from the Norwegian National Body

4.4: 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.

Accepted.

4.8: 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.

Accepted.

4.12: 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.

Rejected. The meeting in Amsterdam decided against this.

5.15: 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.

Accepted. This will be revisited.

Comments from the UK National Body

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.

Accepted. The URIs will be changed to psi.topicmaps.com, which will clearly state that it is only used for PSIs defined by ISO.

4.1.4: Datatype attribute should be defined as string in relation to comment made on [datatype] property.

Rejected, with the same rationale.

4.8: Content model should read:

{id?, parameters, (variantName, variant*) | variant +}
or deserialization in 5.8/5.9 needs to specify a default variantName value.

Accepted. Modifying the content model would be optimal, but cannot be done, as this would mean breaking backwards compatibility with XTM 1.0. Instead, the document will be updated to specify what happens when the <variantName> child is not present.

4.16: Content model should read:

{id?, roleSpec?, topic-reference+ }

Rejected. This modification would make sense, but would break backwards compatibility, and so is not an option. The text already specifies what to do when no references are present.

5.2.7: 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 ?

Yes, it is. This is specified in 5.13 and 5.9.

5.13: 1. Rewrite first sentence of last paragraph as a separate para. 2. Note that [datatype] property should be set to the value of the datatype *attribute*

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

1: Accepted.

2: Accepted.

3: Rejected. This decision may be changed if the UK National Body can produce arguments for why this should be allowed.

Comments from the US National Body

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.

Accepted.

3 Terms and definitions: The definitions should be complete sentences with punctuation.

Rejected. However, the ISO directives, fifth edition, part 2, clause D.1.5.3 state that "the form of a definition shall be such that it can replace the term in context". The editors will update the definitions accordingly.

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?

The xlink:href attribute is required because without it the elements that carry it are meaningless. The advantage of not requiring xlink:type is that it makes XTM documents much smaller, and xlink:type carries no useful information for XTM processors, anyway.

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.

Accepted. A declaration will be added.

4.4 The topic element: "element type"

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

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

1. Accepted. The usage in section 5 will be made more consistent.

2. Rejected. The term "element type" dates back to SGML and is obviously what is meant here.

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.

Accepted. The text will be revised.

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.

Rejected. The declaration is for the element type, not for an individual element instance.

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

Rejected. Topic elements do not have topic names, only topics.

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

1. First, strike the "to create a variant name...." 2. Second, the variant name is not "of a base name" but a variant name for the topic element. 3. 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.

1. Accepted. The text will be revised.

2. Rejected. The proper term is "topic name".

3. Accepted. The text will be revised.

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

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

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

1. Accepted. This will be revisited.

2. Accepted. The term "XTM" will be defined.

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.

Accepted. Usage will be made consistent.

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.

Accepted. This will be clarified.

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.

Rejected. The difference between the reviewed text and the suggested text is the assertion in the reviewed text that all the association roles must have the same type. As the association roles all must have the same type it seems best to leave this in.

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

1. Three problems, first, when is the id attribute ignored and when is it used? 2. 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. 3. 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?

1. Accepted. This will be made clearer.

2. Accepted.

3. Accepted. The wording in 5.15 is removed.

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

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

1. Accepted. The text will be revised.

2. 13250-4 is about canonicalization, which is a special form of serialization that isn't generally useful. Serialization to XTM is implicitly defined in -3, and only -3.

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

It's not clear that this is a problem in any way.

5.5 The subjectIdentity Element: First sentence, "of the child element" should read "of its child elements."

Accepted.

5.9 The variantName Element: First sentence, "of its child element" should read "of its child elements." Note plural.

Accepted.

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.

Accepted.

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

Accepted.

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?

Rejected. Directing the reader to the text describing the processing of these elements clearly makes the document easier to follow.

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.

Accepted. This will be made clearer.

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.

Rejected, for same reasons. There is in any case no repetition, only a (complicated) cross-reference.

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.

Accepted.

5.18 The resourceRef element (first paragraph): Same comment as noted for 5.16 and 5.17. Unnecessary and may lead to conflicting interpretations.

Rejected, for same reason.

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.

Accepted.

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.

Accepted. The text will be revised.

Correspondence of Annexes A, B and C: 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.

Accepted.

Correspondence of Annexes A, B and C: 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.

Accepted.

Correspondence of Annexes A, B and C: 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.

Accepted. The content model in the DTD will be changed to ANY.

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

Accepted. This will be added.