[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xtm-wg] More feedback on spec
Steve/Graham/AG:
This takes me as far as the annexes.
As before, there are substantive (I hope) comments intermixed with
copy edits.
The substantive issues are marked with "**" and remarks are put
in square brackets []. Many of these are "consensus" issues.
One such consensus issue is the omission of "normative" and
"informative" from the Annexes. I strongly believe there
was no AG consensus to take this step.
S.
---------------------------------------
3.1 Introduction to XTM syntax
a. para starting "following is:
** [Sort list of element types alphabetically, please. Much
easier to scan and use as a quick reference.]
b. bullet "subjectIdentity"
Delete
by Topic
replace
by a Topic
** NOTE: I find the capitalization of "topic" and "Topic" very
confusing.
What is the principal? Ditto, "association", "Association". Is the
lower
case informal, and just the idea, or the term as defined in the
glossary,
and the uppercase the Topic Concept as illusrated in the abstract
conceptual model? If there is no clear distinction, suggest lowercase
throughout except in the CM Annex, where uppercasing seems deeply
embedded in the style. If there is a clear distinction, please
document.
c. bullet "subjectIndicator"
delete
subject indicator
replace
subject indicator resource
d. bullet "scope"
delete
topics that
replace
topic or topics
e. bullet "mergemap"
delete
external Topic Map
replace
a second topic map
[could be two topic maps in same document, in that case "external" is
ambiguous
** f. bullet "basename
Delete
Or Occurrence
3.2.1 topicRef element
** a. THANK YOU for the "occurs in" material
[I note, though, that this is sorted, proving that the bulleted list
in 3.1
should be as well.]
b. para starting "the first"
delete
The first of these
replace
The first of these examples
c. para starting "FIXME in cases"
[QUERY: wonder if a place to discuss this is the topic map document
section
in the terminology section. Also query MA on impact of xml:base. Take
wording in para 2 of 3.5.1 into account after decision ("only the
subtree").
3.2.2 subjectIndicatorRef
a. para starting "the subjectIndicatorRef"
** QUERY: Either eliminate "subject identity point" wording or add the
definition back into the glossary. Personally, I'm uncomfortable with
the loss of the distinction between subject constituting and subject
indicating resource, and wonder about its impact (if any) on (dread
word) reification.
3.3.1 Scope
a. Para starting "The <scope> element"...
Delete
"The <scope> ... types." This duplicates the "occurs in" para
below.
b. Para starting "The <scope> element"...
Here again we see "subject identity point". Define the term, or
reword to avoid.
c. bullets starting <topicRef>, <resourceRef>, <subjectIndicatorRef>
Delete
context
Replace
scope
d. Sort the "occurs in" para
3.4.1 <instanceOf> element
a. para starting "The <instanceOf>"
delete
via
replace
via its
b. sort the "occurs in" para
c. bullet starting"<subjectIndicatorRef>
"subject identity point" again.
d. para starting "in the below example"
delete
in the below example
replace
in the example below
3.5.1 <topicMap> element
a. para starting "<topic>"
QUERY: Should "express" be reify?
b. para starting "By definition"
** [see Section 2.3.1 and XMTP are both wrong, since there
is no XMTP anymore.]
QUERY: Has anyone checked the cross references?
c. para starting "However"
seems that "fully processed" is congruent with notion
of "consistent topic set" but should wording not be
reconciled?
d. para starting "<subjectIdentity>
Delete
specifies the subject identity the
Replace
specifies the subject identity of the
3.6.2 <subjectIdentity>
a. para starting "The <subjectIdentity>"
delete
real-world
[Agree here with Bernard Vatant]
b. paras starting "when a topic" and "when the subject"
** This explains, without naming it, the distinction
between a subject constituting, and subject indicating
resource. Given that, why not put subject identity
back in, since it explains that distinction, which
does after all need to be explained in the spec, as here?
c. para starting "FIXME"
[since "harmony" is in the eye of the human, the ultimate
arbiter, "by definition" they are harmonious. It's a QA
issue, ultimately.]
d. in list of elements, for symmetry -- since "is" is
highlighted in <resourceRef>, highlight "has the same
subject as" and "indicates the subject of" in the following
two items. Or unbold the first.
3.7.1 <baseName> element
a. para starting "The <baseName> element"
delete
"context"
replace
"scope"
delete
"certain name"
replace
"name"
b. para starting "During XTM"
** Surely this cross reference is obsolete? No XTMP.
c. para starting "XTM Langauge topics"
Move this to follow para starting "A topic may have several"
since it is a natural continuation of the thought expressed
there.
d. para starting "XTM Langauge topics"
delete
other possible methods
replace
other possible subject indicators for natural languages
[Cannot say on the one hand "must be specified by a child
scope element" and on the other "does not constrain
other possible methods."]
e. para starting "<scope>"
delete
context
replace
scope
e. para starting "<scope>"
delete
baseName
replace
parant <baseName> element
f. para starting "the example below"
delete
possible means
replace
possible method
g. para starting "1. the one"
delete
the one in the unconstrained scope is
replace
the first, in the unconstrained scope, is
h. para starting "2. the full"
delete
the full name is in the scope ... ; and
replace
the second, scoped by "plays" and "fullname", gives
the full name of the play
i. para starting "3. the unq"
delete
the unqualified
replace
the third, unqualified
j. example whose id is "character-hamlet"
QUERY: Should not this example be deleted? I can't see what
it ties into.
3.7.3
a. para that starts "the <variant>"
** I am so careful about using the word "context" because I think
it is very easy to confuse that word with the phrase "processing
context" which has a precise definition given here.
b. para starting "Each <variantName>"
delete
are inherited
replace
inherit
[A chance to kill the passive voice!]
c. para starting "a variant"
delete
semantically
replace
functionally
3.7.5 <parameters>
a. para that starts "The <parameters>"
delete
a subject indicator
replace
<subjectIndicatorRef>
b. para starting "<subjectIndicatorRef>"
Note again use of "subject identity point". Define or reword.
3.8.1 Association
a. Trivial, or not so:
** [QUERY: Quotes are mixed in the current version. Some are curly
("typographer's"), some are straight. Check with MA for
useability issues and general web display issues.]
b. para starting "the context"
delete
context
replace
scope
3.8.3 <roleSpec> element
a. para starting "The <roleSpec> element is a syntactic shortcut
for an association of a special type defined by the PSI class-instance"
** [There is no consensus on this paragraph. Heck, if this were so,
why is no one advocating using instanceOf, which provides the
identical PSI without using an obfuscatory generic identifier? The
reason is, there was no consensus that a roleSpec is indeed an
instanceOf. This feels very much to me like another attempt at
a templating mechanism, again about which there is no consensus.]
3.9.1 <occurrence> element
a. para starting "the optional <baseName>"
Delete para to reflect DTD erratum.
b. para starting "<baseName>"
Ditto.
c. para starting "The optional"
delete
context
replace
scope
3.9.3 <resourceRef>
a. As in 2.2.3 add disclaimer:
<resourceData> provides a syntactically convenient means of
labelling.
It should never be used for any other purpose, for example,
metadata, as that would defeat reliable interchange of topic
maps.
3.10.1 Merging
a. As in 3.1 (qv)
delete
external <topicMap> element
replace
a second topic map
b. note use of subject identity point in 3 list items. Define
or reword.
** Finally, in the TOC, the Annexes should be retitled to reflect
the consensus on normative/informative achieved in Paris. It was:
ANNEXES
DTD (Normative) DRAFTED (Core)
Published Subject Indicators (Normative) DRAFTED (Core)
Conceptual Model (Informative) DRAFTED
Mapping from CM to Syntax (Informative)INITIAL DRAFT
Processing Model (Informative) INITIAL DRAFT
Glossary (Informative) DRAFTED
Acknowledgements (Informative) DRAFTED
Certainly, for example, there can be no consensus
that the Annex titled "Mapping from CM to Syntax"
is normative -- no one in the AG had a chance to
examine it before February 1.
Steve/Graham/AG:
This takes me as far as the annexes.
As before, there are substantive (I hope) comments intermixed with
copy edits.
The substantive issues are marked with "**" and remarks are put
in square brackets []. Many of these are "consensus" issues.
One such consensus issue is the omission of "normative" and
"informative" from the Annexes. I strongly believe there
was no AG consensus to take this step.
S.
---------------------------------------
3.1 Introduction to XTM syntax
a. para starting "following is:
** [Sort list of element types alphabetically, please. Much
easier to scan and use as a quick reference.]
b. bullet "subjectIdentity"
Delete
by Topic
replace
by a Topic
** NOTE: I find the capitalization of "topic" and "Topic" very
confusing.
What is the principal? Ditto, "association", "Association". Is the
lower
case informal, and just the idea, or the term as defined in the
glossary,
and the uppercase the Topic Concept as illusrated in the abstract
conceptual model? If there is no clear distinction, suggest lowercase
throughout except in the CM Annex, where uppercasing seems deeply
embedded in the style. If there is a clear distinction, please
document.
c. bullet "subjectIndicator"
delete
subject indicator
replace
subject indicator resource
d. bullet "scope"
delete
topics that
replace
topic or topics
e. bullet "mergemap"
delete
external Topic Map
replace
a second topic map
[could be two topic maps in same document, in that case "external" is
ambiguous
** f. bullet "basename
Delete
Or Occurrence
3.2.1 topicRef element
** a. THANK YOU for the "occurs in" material
[I note, though, that this is sorted, proving that the bulleted list
in 3.1
should be as well.]
b. para starting "the first"
delete
The first of these
replace
The first of these examples
c. para starting "FIXME in cases"
[QUERY: wonder if a place to discuss this is the topic map document
section
in the terminology section. Also query MA on impact of xml:base. Take
wording in para 2 of 3.5.1 into account after decision ("only the
subtree").
3.2.2 subjectIndicatorRef
a. para starting "the subjectIndicatorRef"
** QUERY: Either eliminate "subject identity point" wording or add the
definition back into the glossary. Personally, I'm uncomfortable with
the loss of the distinction between subject constituting and subject
indicating resource, and wonder about its impact (if any) on (dread
word) reification.
3.3.1 Scope
a. Para starting "The <scope> element"...
Delete
"The <scope> ... types." This duplicates the "occurs in" para
below.
b. Para starting "The <scope> element"...
Here again we see "subject identity point". Define the term, or
reword to avoid.
c. bullets starting <topicRef>, <resourceRef>, <subjectIndicatorRef>
Delete
context
Replace
scope
d. Sort the "occurs in" para
3.4.1 <instanceOf> element
a. para starting "The <instanceOf>"
delete
via
replace
via its
b. sort the "occurs in" para
c. bullet starting"<subjectIndicatorRef>
"subject identity point" again.
d. para starting "in the below example"
delete
in the below example
replace
in the example below
3.5.1 <topicMap> element
a. para starting "<topic>"
QUERY: Should "express" be reify?
b. para starting "By definition"
** [see Section 2.3.1 and XMTP are both wrong, since there
is no XMTP anymore.]
QUERY: Has anyone checked the cross references?
c. para starting "However"
seems that "fully processed" is congruent with notion
of "consistent topic set" but should wording not be
reconciled?
d. para starting "<subjectIdentity>
Delete
specifies the subject identity the
Replace
specifies the subject identity of the
3.6.2 <subjectIdentity>
a. para starting "The <subjectIdentity>"
delete
real-world
[Agree here with Bernard Vatant]
b. paras starting "when a topic" and "when the subject"
** This explains, without naming it, the distinction
between a subject constituting, and subject indicating
resource. Given that, why not put subject identity
back in, since it explains that distinction, which
does after all need to be explained in the spec, as here?
c. para starting "FIXME"
[since "harmony" is in the eye of the human, the ultimate
arbiter, "by definition" they are harmonious. It's a QA
issue, ultimately.]
d. in list of elements, for symmetry -- since "is" is
highlighted in <resourceRef>, highlight "has the same
subject as" and "indicates the subject of" in the following
two items. Or unbold the first.
3.7.1 <baseName> element
a. para starting "The <baseName> element"
delete
"context"
replace
"scope"
delete
"certain name"
replace
"name"
b. para starting "During XTM"
** Surely this cross reference is obsolete? No XTMP.
c. para starting "XTM Langauge topics"
Move this to follow para starting "A topic may have several"
since it is a natural continuation of the thought expressed
there.
d. para starting "XTM Langauge topics"
delete
other possible methods
replace
other possible subject indicators for natural languages
[Cannot say on the one hand "must be specified by a child
scope element" and on the other "does not constrain
other possible methods."]
e. para starting "<scope>"
delete
context
replace
scope
e. para starting "<scope>"
delete
baseName
replace
parant <baseName> element
f. para starting "the example below"
delete
possible means
replace
possible method
g. para starting "1. the one"
delete
the one in the unconstrained scope is
replace
the first, in the unconstrained scope, is
h. para starting "2. the full"
delete
the full name is in the scope ... ; and
replace
the second, scoped by "plays" and "fullname", gives
the full name of the play
i. para starting "3. the unq"
delete
the unqualified
replace
the third, unqualified
j. example whose id is "character-hamlet"
QUERY: Should not this example be deleted? I can't see what
it ties into.
3.7.3
a. para that starts "the <variant>"
** I am so careful about using the word "context" because I think
it is very easy to confuse that word with the phrase "processing
context" which has a precise definition given here.
b. para starting "Each <variantName>"
delete
are inherited
replace
inherit
[A chance to kill the passive voice!]
c. para starting "a variant"
delete
semantically
replace
functionally
3.7.5 <parameters>
a. para that starts "The <parameters>"
delete
a subject indicator
replace
<subjectIndicatorRef>
b. para starting "<subjectIndicatorRef>"
Note again use of "subject identity point". Define or reword.
3.8.1 Association
a. Trivial, or not so:
** [QUERY: Quotes are mixed in the current version. Some are curly
("typographer's"), some are straight. Check with MA for
useability issues and general web display issues.]
b. para starting "the context"
delete
context
replace
scope
3.8.3 <roleSpec> element
a. para starting "The <roleSpec> element is a syntactic shortcut
for an association of a special type defined by the PSI class-instance"
** [There is no consensus on this paragraph. Heck, if this were so,
why is no one advocating using instanceOf, which provides the
identical PSI without using an obfuscatory generic identifier? The
reason is, there was no consensus that a roleSpec is indeed an
instanceOf. This feels very much to me like another attempt at
a templating mechanism, again about which there is no consensus.]
3.9.1 <occurrence> element
a. para starting "the optional <baseName>"
Delete para to reflect DTD erratum.
b. para starting "<baseName>"
Ditto.
c. para starting "The optional"
delete
context
replace
scope
3.9.3 <resourceRef>
a. As in 2.2.3 add disclaimer:
<resourceData> provides a syntactically convenient means of
labelling.
It should never be used for any other purpose, for example,
metadata, as that would defeat reliable interchange of topic
maps.
3.10.1 Merging
a. As in 3.1 (qv)
delete
external <topicMap> element
replace
a second topic map
b. note use of subject identity point in 3 list items. Define
or reword.
** Finally, in the TOC, the Annexes should be retitled to reflect
the consensus on normative/informative achieved in Paris. It was:
ANNEXES
DTD (Normative) DRAFTED (Core)
Published Subject Indicators (Normative) DRAFTED (Core)
Conceptual Model (Informative) DRAFTED
Mapping from CM to Syntax (Informative)INITIAL DRAFT
Processing Model (Informative) INITIAL DRAFT
Glossary (Informative) DRAFTED
Acknowledgements (Informative) DRAFTED
Certainly, for example, there can be no consensus
that the Annex titled "Mapping from CM to Syntax"
is normative -- no one in the AG had a chance to
examine it before February 1.
Steve/Graham/AG:
This takes me as far as the annexes.
As before, there are substantive (I hope) comments intermixed with
copy edits.
The substantive issues are marked with "**" and remarks are put
in square brackets []. Many of these are "consensus" issues.
One such consensus issue is the omission of "normative" and
"informative" from the Annexes. I strongly believe there
was no AG consensus to take this step.
S.
---------------------------------------
3.1 Introduction to XTM syntax
a. para starting "following is:
** [Sort list of element types alphabetically, please. Much
easier to scan and use as a quick reference.]
b. bullet "subjectIdentity"
Delete
by Topic
replace
by a Topic
** NOTE: I find the capitalization of "topic" and "Topic" very
confusing.
What is the principal? Ditto, "association", "Association". Is the
lower
case informal, and just the idea, or the term as defined in the
glossary,
and the uppercase the Topic Concept as illusrated in the abstract
conceptual model? If there is no clear distinction, suggest lowercase
throughout except in the CM Annex, where uppercasing seems deeply
embedded in the style. If there is a clear distinction, please
document.
c. bullet "subjectIndicator"
delete
subject indicator
replace
subject indicator resource
d. bullet "scope"
delete
topics that
replace
topic or topics
e. bullet "mergemap"
delete
external Topic Map
replace
a second topic map
[could be two topic maps in same document, in that case "external" is
ambiguous
** f. bullet "basename
Delete
Or Occurrence
3.2.1 topicRef element
** a. THANK YOU for the "occurs in" material
[I note, though, that this is sorted, proving that the bulleted list
in 3.1
should be as well.]
b. para starting "the first"
delete
The first of these
replace
The first of these examples
c. para starting "FIXME in cases"
[QUERY: wonder if a place to discuss this is the topic map document
section
in the terminology section. Also query MA on impact of xml:base. Take
wording in para 2 of 3.5.1 into account after decision ("only the
subtree").
3.2.2 subjectIndicatorRef
a. para starting "the subjectIndicatorRef"
** QUERY: Either eliminate "subject identity point" wording or add the
definition back into the glossary. Personally, I'm uncomfortable with
the loss of the distinction between subject constituting and subject
indicating resource, and wonder about its impact (if any) on (dread
word) reification.
3.3.1 Scope
a. Para starting "The <scope> element"...
Delete
"The <scope> ... types." This duplicates the "occurs in" para
below.
b. Para starting "The <scope> element"...
Here again we see "subject identity point". Define the term, or
reword to avoid.
c. bullets starting <topicRef>, <resourceRef>, <subjectIndicatorRef>
Delete
context
Replace
scope
d. Sort the "occurs in" para
3.4.1 <instanceOf> element
a. para starting "The <instanceOf>"
delete
via
replace
via its
b. sort the "occurs in" para
c. bullet starting"<subjectIndicatorRef>
"subject identity point" again.
d. para starting "in the below example"
delete
in the below example
replace
in the example below
3.5.1 <topicMap> element
a. para starting "<topic>"
QUERY: Should "express" be reify?
b. para starting "By definition"
** [see Section 2.3.1 and XMTP are both wrong, since there
is no XMTP anymore.]
QUERY: Has anyone checked the cross references?
c. para starting "However"
seems that "fully processed" is congruent with notion
of "consistent topic set" but should wording not be
reconciled?
d. para starting "<subjectIdentity>
Delete
specifies the subject identity the
Replace
specifies the subject identity of the
3.6.2 <subjectIdentity>
a. para starting "The <subjectIdentity>"
delete
real-world
[Agree here with Bernard Vatant]
b. paras starting "when a topic" and "when the subject"
** This explains, without naming it, the distinction
between a subject constituting, and subject indicating
resource. Given that, why not put subject identity
back in, since it explains that distinction, which
does after all need to be explained in the spec, as here?
c. para starting "FIXME"
[since "harmony" is in the eye of the human, the ultimate
arbiter, "by definition" they are harmonious. It's a QA
issue, ultimately.]
d. in list of elements, for symmetry -- since "is" is
highlighted in <resourceRef>, highlight "has the same
subject as" and "indicates the subject of" in the following
two items. Or unbold the first.
3.7.1 <baseName> element
a. para starting "The <baseName> element"
delete
"context"
replace
"scope"
delete
"certain name"
replace
"name"
b. para starting "During XTM"
** Surely this cross reference is obsolete? No XTMP.
c. para starting "XTM Langauge topics"
Move this to follow para starting "A topic may have several"
since it is a natural continuation of the thought expressed
there.
d. para starting "XTM Langauge topics"
delete
other possible methods
replace
other possible subject indicators for natural languages
[Cannot say on the one hand "must be specified by a child
scope element" and on the other "does not constrain
other possible methods."]
e. para starting "<scope>"
delete
context
replace
scope
e. para starting "<scope>"
delete
baseName
replace
parant <baseName> element
f. para starting "the example below"
delete
possible means
replace
possible method
g. para starting "1. the one"
delete
the one in the unconstrained scope is
replace
the first, in the unconstrained scope, is
h. para starting "2. the full"
delete
the full name is in the scope ... ; and
replace
the second, scoped by "plays" and "fullname", gives
the full name of the play
i. para starting "3. the unq"
delete
the unqualified
replace
the third, unqualified
j. example whose id is "character-hamlet"
QUERY: Should not this example be deleted? I can't see what
it ties into.
3.7.3
a. para that starts "the <variant>"
** I am so careful about using the word "context" because I think
it is very easy to confuse that word with the phrase "processing
context" which has a precise definition given here.
b. para starting "Each <variantName>"
delete
are inherited
replace
inherit
[A chance to kill the passive voice!]
c. para starting "a variant"
delete
semantically
replace
functionally
3.7.5 <parameters>
a. para that starts "The <parameters>"
delete
a subject indicator
replace
<subjectIndicatorRef>
b. para starting "<subjectIndicatorRef>"
Note again use of "subject identity point". Define or reword.
3.8.1 Association
a. Trivial, or not so:
** [QUERY: Quotes are mixed in the current version. Some are curly
("typographer's"), some are straight. Check with MA for
useability issues and general web display issues.]
b. para starting "the context"
delete
context
replace
scope
3.8.3 <roleSpec> element
a. para starting "The <roleSpec> element is a syntactic shortcut
for an association of a special type defined by the PSI class-instance"
** [There is no consensus on this paragraph. Heck, if this were so,
why is no one advocating using instanceOf, which provides the
identical PSI without using an obfuscatory generic identifier? The
reason is, there was no consensus that a roleSpec is indeed an
instanceOf. This feels very much to me like another attempt at
a templating mechanism, again about which there is no consensus.]
3.9.1 <occurrence> element
a. para starting "the optional <baseName>"
Delete para to reflect DTD erratum.
b. para starting "<baseName>"
Ditto.
c. para starting "The optional"
delete
context
replace
scope
3.9.3 <resourceRef>
a. As in 2.2.3 add disclaimer:
<resourceData> provides a syntactically convenient means of
labelling.
It should never be used for any other purpose, for example,
metadata, as that would defeat reliable interchange of topic
maps.
3.10.1 Merging
a. As in 3.1 (qv)
delete
external <topicMap> element
replace
a second topic map
b. note use of subject identity point in 3 list items. Define
or reword.
** Finally, in the TOC, the Annexes should be retitled to reflect
the consensus on normative/informative achieved in Paris. It was:
ANNEXES
DTD (Normative) DRAFTED (Core)
Published Subject Indicators (Normative) DRAFTED (Core)
Conceptual Model (Informative) DRAFTED
Mapping from CM to Syntax (Informative)INITIAL DRAFT
Processing Model (Informative) INITIAL DRAFT
Glossary (Informative) DRAFTED
Acknowledgements (Informative) DRAFTED
Certainly, for example, there can be no consensus
that the Annex titled "Mapping from CM to Syntax"
is normative -- no one in the AG had a chance to
examine it before February 1.
=====
<!-- "To imagine a language is to imagine a form of life."
- Ludwig Wittgenstein, Philosophical Investigations -->
__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/
------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/337252/_/981158298/
---------------------------------------------------------------------_->
To Post a message, send it to: xtm-wg@eGroups.com
To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC