-
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.
-
3 Terms and definitions
The definitions should be complete sentences with
punctuation.
-
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.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.
-
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.
-
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.
-
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.
-
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."
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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?
-
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.
-
5.5 The subjectIdentity Element
First sentence, "of the child element" should read "of its child
elements."
-
5.9 The variantName Element
First sentence, "of its child element" should read "of its child
elements." Note plural.
-
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.
-
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).
-
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?
-
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.
-
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.
-
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.
-
5.18 The resourceRef element (first paragraph)
Same comment as noted for 5.16 and 5.17. Unnecessary and may
lead to conflicting interpretations.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Annex E:
There is no mention in Annex E of the change of the content
model of resourceData from PCDATA to any markup.
