[sc34wg3] parid0398

[Sam Hunting]

REF: parid0398 parid0399 parid0970 parid0989 parid0971 parid 0423
parid2014 parid2226 parid0294
TXT: syntax processing model
FIX: syntax processing procedures
COM: No need to introduce the confusing "model" here. See also parid0294,
parid0398, parid0399, parid0423, parid0970, parid0971, parid0989,
parid2014, parid2226.

REF: parid0402
TXT:  A list of syntactic constructs ("node demanders") whose instances
can be unambiguously addressed within the instances of the syntax must be
provided.
FIX: The Syntax Processing Procedures must provide a list of syntactic
constructs ("node demanders") whose instances
can be unambiguously addressed within the instances of the syntax must be
provided.
END

REF: parid0402
TXT:  Each such node demander must be defined as being associated with a
specific node whose existence in the topic map graph that the instance
represents can reasonably be regarded as being "demanded" by the existence
of the demander.

FIX: The definition of each such node demander must specify the situation
feature in the topic map graph of the SPP's governing application that is
to be regarded as having been demanded by the existence of the demander.
COM: Demanders don't demand specific nodes, do they?
END

REF: parid0974
TXT: Each TM Application that defines one or more Syntax Processing Models
must also define at least one assertion type of which one of the role
types can be played by a node demander, that confers one or more SIDP
values on the player of another of its role types such that its subject
will be recognized by the merging process as being the same as the subject
of the node whose existence is demanded by the node demander.
COM: It is not clar to me how there can be an "asertion type" wihtout all
the roles being defined explicitly (cf "another of its role types")
END

REF: parid0974
COM: Revise for readability.
END

REF: parid0405
TXT: Borrowed definitions
FIX: Included TM Applications
COM: Borrowing implies giving back, interest, etc. "Include" is more
connotation free. See also parid0433 and  parid0920.
END

REF: parid0433
TXT: borrowed
FIX: included
COM: See also parid0405, parid0920.

REF: parid0920
TXT: borrowed
FIX: included
COM: See also parid0405, parid0433.

REF: parid0406
TXT: The names of borrowed properties, assertion types and role types are
not affected by being borrowed; each remains as defined in the definition
of its TM Application of origin.
FIX: (delete?)
COM: Seems to imply that the definitions are *not* included as their
entirely (semantics and all). Also, is there a rule for resolving name
clashes? Does there need to be?
END

REF: parid0394
TXT: The definition of a Topic Maps Application may or may not define one
or more syntaxes for the interchange of the topic maps it governs.
FIX: The definition of a Topic Maps Application may or may not define one
or more syntaxes for the interchange of the topic map graphs it governs.
END

REF: parid0970
TXT: a Syntax Processing Model specifies how to construct topic map graphs
from instances of the syntax, without omitting any information represented
in the instances. 

FIX: Syntax Processing Procedures specify how to construct a topic map
graph from an instance of the syntax, without omitting any of the inherent
topic map information represented in the instance.
END

REF: parid0991
TXT: Built-in values cannot be overridden by virtue of the node's
situation in the graph.

FIX: A node's built-in values, if any, cannot be overridden by virtue of
the node's situation in the graph.
END

REF: parid0414
TXT: This RM4TM is designed to allow all well-formed topic
map graphs, regardless of their governing TM Application(s), to be
processed in essentially the same way, in order to achieve the result of a
fully-merged topic map graph.
FIX: This RM4TM enables a uniform process for fully merging all 
well-formed topic map graphs, regardless of their governing TM Application(s).
COM: Why "essentially"?
END

REF: parid0421
COM: Very unclear. What is a "new" graph? What is the difference between
"endow" and "demand" (Could we think of endowment as a logical
demanding?) The headline in parid0420 mentions nodes only, but nodes and
arcs are in the text. parid0247 discusses bootstrapping assertion types,
but they are not mentioned here. Why?
END

REF: parid0421
TXT: governing TM Application's ontology
FIX: governing TM Application.
COM: Reserve "ontology" for nmarketing sections only.
END

REF: parid0423

COM: Very unclear. "If" seems to imply that there are other ways of
constructing a topic map graph than from topic map interchange syntax.
(Actually, we know of one already -- "endowment" in parid0421.) But if
that is so, where is the checklist item for defining it? In what way is
"output" "added"? Is that merging? And the grpah is an output?
END

REF: parid0429
COM: Revise for readabilty.
END



 Sam Hunting eTopicality, Inc.

---------------------------------------------------------------------------
Co-Editor, ISO Reference Model for Topic Maps 

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.gooseworks.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------