| 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
|
|
|
|
|
(1) General
Information item types and their properties
should be in consistency between TMDM and Canonicalization. The
"locator item" and its properties should be deleted or
changed.
(2) Technical
(2.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.2) Clause 3 Normalisation of Locator
References
Definition of Normalisation process (item 1 - 4) is hard to
understand. The following examples should be added.
Let us say that the locator to be normalised is
http://www.isotopicmaps.org/sam/cxtm/sample.xtm#S02?q01.
Let us also assume that the base locator of the topic map is
http://www.isotopicmaps.org/sam/cxtm/sample.xtm.
Let us use the value L as the current normalised value of the input locator.
The result of step 1 should be:
P = http://www.isotopicmaps.org/sam/cxtm/sample.xtm
L = http://www.isotopicmaps.org/sam/cxtm/sample.xtm#S02?q01
After step 2 (L starts with P, so remove the entire substring from L)
P = http://www.isotopicmaps.org/sam/cxtm/sample.xtm
L = #S02?q01
Let us now consider the case where the input locator is
http://www.isotopicmaps.org/sam/sam-model/#d0e592
After step 1
P = http://www.isotopicmaps.org/sam/cxtm/sample.xtm
L = http://www.isotopicmaps.org/sam/sam-model/#d0e592
After step 2 (there is no match found)
P = http://www.isotopicmaps.org/sam/cxtm/sample.xtm
L = http://www.isotopicmaps.org/sam/sam-model/#d0e592
After step 3
P = http://www.isotopicmaps.org/sam/cxtm
L = http://www.isotopicmaps.org/sam/sam-model/#d0e592
After step 2 (again no match found)
P = http://www.isotopicmaps.org/sam/cxtm
L = http://www.isotopicmaps.org/sam/sam-model/#d0e592
After step 3
P = http://www.isotopicmaps.org/sam
L = http://www.isotopicmaps.org/sam/sam-model/#d0e592
After step 2 (L starts with P, so remove the entire substring and
the '/' separator from L)
P = http://www.isotopicmaps.org/sam
L = sam-model/#d0e592
(2.3) Clause 4.2 Information Type and Basic
Type Sort Order
The "Basic Type" should be the "Fundamental Type". Because it is
not the "Basic Type" but the "Fundamental Type" in TMDM.
(2.4) Clause 4.8 Canonical Sort Order For
Variant Items
The "[resource]" should be the "[datatype]", in order to be
consistent with the Equality rule of Variant Items in
TMDM.
(2.5) Clause 4.9 Canonical Sort Order For
Occurrence Items
The "[resource]" should be the "[datatype]", in order to be
consistent with the Equality rule of Occurrence Items in
TMDM.
(2.6) Clause 4.11 Canonical Sort Order For
Association Role Items
The "[role playing topic]" should be the "[player]", in order to be
consistent with the Equality rule of Association Role Items in
TMDM.
(2.7) Clause 5.7 Constructing a representation
of a topic map information item
The "topic map information item" in title should be the "topic map
item", in order to be consistent with other items.
(2.8) Clause 5.15 - 5.20 Constructing a
representation of the [....] property
Only 6 properties (reifier, reified, scope, source locators, type
and value) are defined at the moment. In addition to them, all
properties should be defined.
(3) Editorial
(3.1) All part of the specification
Some words have two kinds of spell, for example "normalize and
normalise". The words should be unified.
(3.2) Clause 2. Normative references
"ISO10646-1, ISO 10646-1:2000: ... " and ISO10646-2, ISO
10646-2:2001:" should be
"ISO/IEC 10646: 2003: ... ".
(3.3) Clause 2 Normative references
Version of Unicode should be 4.0.
(3.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>".
(3.5) 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.
(3.6) Clause 2 Normative references
"XML Infoset, XML Information Set, ... " should be
"XML Information Set (Second Edition), World Wide Web Consortium, 4
February 2004, available at
<http://www.w3.org/TR/2004/REC-xml-infoset-20040204/>".
|
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
|
1, 2, 3, 4, 5
|
|
ge
|
This part of ISO 13250 must be
aligned with part 2.
|
|
|
|
NO
|
3, 4, 5
|
|
ed
|
The order of exposition makes the
document hard to understand.
|
Reverse the order of sections 3, 4,
and 5.
|
|
|
NO
|
3
|
|
te
|
The specified algorithm sometimes leads to
locators that are different being canonicalized as though they were
the same. For example, if the [base locator] property is
"file:/home/myhome/mytopicmap.xtm" the following
locators
"file:/home/myhome/mytopicmap.xtm#foo"
"file:/home/myhome/#foo"
"file:/home/#foo"
"file:/#foo"
are all canonicalized to
"#foo".
|
Change the algorithm, for example to produce
the following canonical output:
"#foo"
"../#foo"
"../../#foo"
"../../../#foo"
|
|
|
NO
|
5
|
|
te
|
There is no convention for
inserting whitespace into CXTM output. This will lead to output
that is difficult to debug.
|
Define conventions for inserting
white-space, e.g. line-break after every end- tag in element
content.
|
|
|
NO
|
5.3
|
|
te
|
It is unnecessarily difficult to
debug CXTM output because references to elements are by positional
value (e.g., <type topicref="1370">) but the positional
values are not stated explicitly on the elements
themselves.
|
XML elements which are referred to
by positional value should have an attribute that specifies the
positional value, e.g. <topic num="1370">, etc.
|
|
The UK cannot approve this draft as it is not aligned with the current text of Part 2.
-
The title as balloted is "Canonical Syntax." The FCD draft,
however, bears the title "Canonicalization."
The earliest committee draft bore the title: "Canonical XTM: A
canonical serialization format for topic maps," see
N395. The CD ballot document, N484, billed itself as
"Canonicalization." (See
N454, which is a PDF version of the draft. The current ballot,
however, refers to "Canonical Syntax," see
N590b.
I think balloting "canonical syntax" in this case is
inconsistent with the document itself and in view of its contents,
simply wrong. I am not sure that canonicalization is any better,
but at least the naming should be consistent.
-
Introduction
While non-normative, the introduction should limit itself to the
subject of the standard and not make claims about topic maps in
general. This part is a standard for canonical representation of a
particular data model and should confine the scope of its remarks
accordingly.
Or as better stated in the section on Scope: "This part of
ISO/IEC 13250 specifies an algorithm for the canonicalization of an
instance of the Topic Maps Data Model. It defines a canonical
ordering for every information item defined by the Topic Maps Data
Model and an XML serialisation of the information items and all of
their properties. When the XML is serialized in accordance with
[XML-C14N], the serialized file is the canonical representation of
the Topic Maps Data Model instance."
-
3 Normalization of Locator References (Note, typo)
In the note to this section, note "CXTM process described by
*This* part of" which is taken to be a typo.
-
4.3 Comparison of Set Property Values (1)
Reads: "Sets sort in order of the number of elements in the
collection. A set with fewer elements sorts lower than a set with
more elements."
Have not seen "collection" defined anywhere yet. Assume what is
meant is that a set of sets is sorted by the number of elements in
each set. That is not, however, what is said by the quoted
material.
-
4.3 Comparison of Set Property Values (2)
Reads in part: "The collections then sort in the order of the
non-equal items in each collection."
Does collection = set? Is the sort order that of 4.2 or does it
vary by the nature of the items in the set? (Assume the latter but
it should be stated.
-
5.3 Encoding of positional values
Reads: "When the position of an item in a list is to be encoded,
the encoded value is the index of that item in the list counting
from 1 as the index of the first list item."
Question: Is there a reason to depart from the practice of the
first item in a list having position 0? Thinking that departing
from customary behavior is more likely to cause confusion among
implementers.
