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.
