| 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
Explanation for each item should be
enriched.
2. Technical
"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.
3. Editorial
(3.1) Clause 1 Scope, 2nd paragraph, last
sentence:
"generlised" should be "generalised".
(3.2) Clause 2 Normative
references:
Version of Unicode should be 4.0.
(3.3) 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: rfc3986.txt rfc
www.ietf.org".
(3.4) Clause 2. Normative
references:
"IETF RFC 2732, ... " should be deleted, because
of it is included in IETF RFC 3986.
(3.5) Clause 2. Normative
references:
"IETF RFC 3987, Internationalized Resource
Identifiers (IRIs), Internet Standards Track Specification, January
2005, available at HTTP: rfc www.ietf.org rfc3987.txt" should be
added.
(3.6) Terms and definitions:
The "Terms and definitions" clause should be
added.
(3.7) Clause 3.1 Notation and
Syntax:
"The syntax of TMQL is defined using ... "
should be
"The syntax of TMCL is defined using ... "
(3.8) Clause 4 TMCL, 1st paragraph, last
sentence
"generlised" should be "generalised".
(3.9) Clause 4.2.13, 4.2.14,
4.2.15:
"Plays Role Schema" should be located first of
these three schemas. The appropiate order of these three schemas is
as follows:
- Plays Role Schema
- Role Schema
- Other Player Schema
(3.10) Clause 4.2.20 Syntax for
TMCL-Schema, 2nd definition from bottom:
"element-SimpleTopicExpression = element
OrTopicScheme { ... "
should be
"element-OrTopicExpression = element OrTopicScheme { ...
".
|
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.2
|
|
ed
|
The notation used to define the model should
be explained before it is used and if possible made clearer.
Consider using the infoset formalism already used by 13250-2
(TMDM).
|
|
|
|
NO
|
4.2
|
|
ed
|
For consistency with 13250, use
“type” instead of “class” here and
elsewhere.
|
|
|
|
NO
|
4.2.8
|
|
ed
|
For consistency with 13250, use
“subject locator” instead of “subject
address” here and elsewhere.
|
|
|
|
NO
|
4.2.22
|
|
ed
|
For consistency with 13250, use
“association role” (or “role”) instead of
“member” here and elsewhere.
|
|
|
The formal definitions in the current draft cannot be fully reviewed until some explanatory text is added. The formal language
needs to be properly documented so that reviewers can check the accuracy of the productions (The text in 3.1 is inaccurate.)
Aspects relating to diagnostics and reporting should be left to application developers. Hooks should be used to identify where
and when error conditions are to be reported.
Use Case Requirement: We need to be able to type topics and associations and define which types of topics associations can
be used at specific levels in a "topic hierarchy".
