[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Feedback on Processing Requirements WAS [xtm-wg] Communication back to normal
> So, please rush your comments on the Final Draft of XTM 1.0
> to <pepper@ontopia.net> and <gdm@empolis.co.uk>. The deadline
> is midnight Wednesday Feb 7th EST. (After that the editors
> turn into pumpkins.)
My comments on the processing model are below. Uh, if we could have a
little more notice for feedback than 24 hours in the future it would be
greatly appreciated.
Graham/Kal/Steve/AG:
I like this a lot. It reads in a very clean and clear way.
(I mean that as the highest possible compliment.)
On from the nice things to the nasty ones!
The lack of the topic map graph is affecting me much as I am told a
severed limb does an amputee. So if I sound irritable, it's because I
am trying to scratch something that no longer exists. Howver, I do feel
that some "plane of abstraction" is required to feel the pedagogical
role, if not the technical one, that the graph once played.
Steve, although I greatly appreciated the responses in the Word doc you
posted -- but please can't we at least shroad the aord 'semantic' in
shudder quotes -- it would be very time consuming to do the same thing
for this -- don't feel you must.
There are substantive (I hope) comments intermixed with copy edits.
The substantive issues are marked with "**" and remarks are put
in square brackets [].
S.
F.1 Introduction
a. para starting "This annex"
Delete
one or more instances of documents conforming to the XTM
1.0 DTD
Replace
one or more topic map documents
Delete
information contained
Replace
topic map information contained
** NOTE: see definition of "topic map document" in the
glossary.
The Replace statements say that we can process topic maps
even when they are contained in other documents.
The Delete statements says we have to extract them and
then process them.
The Replace statements conform to 4.4 "Document Conformance"
(see bullets 2 and 3). The Delete statements do not. So
using the Replace statements avoids the situation of having
a conformant XTM document that cannot be processed by
a conformant XTM processor.
Of course the first step of a processor could be to
to do the extractions of the topicMap elements from a
topic map document -- but why specify that this is the
only way to do an implementation?
F.2.1 String equality principle
a. para starting "An XTM processing application"
** Do something, or not, with:
"XTM processing application
throughout the spec.
1. Possibly replace with "An XTM application" (which
is bya "software module" that is by definition
conformant (see 4.5).
2. Possibly replace with "A conformant XTM processor"
Here are the usages:
glossary "the XTM processing application "
F.2.1 "An XTM processing application "
F.2.2 "An XTM processing application "
F.3 "A conformant XTM processing application "
F.5.2 "the XTM processing application "
(WARNING: there may be multiple usages in the same
section. Usages are not flagged with customary
delete/replace.)
In the glossary definition of "processed topic map" there
is a reference to "by the XTM processing application as
defined in Annex F", but the first sentence of the Annex
itself says that it defines "minimal requirements for a
conformant XTM processor." So it looks like the glossary
should be updated.
In the other usages, if it is the intent that there should
be a category of XTM processor that is not conformant, yet
must perform the operations described, we should explain
and justify this.
In the following, I am going to use "A conformant XTM
processor".
b. para starting "An XTM processing application"
Delete
compliant
replace
conformant
(I'm assuming that the transcoding is there to compare
strings that are from non-XML documents.)
Delete
Given this
Replace
Given this transcoding
F.2.2 URI equality principle
a. para starting "An XTM processing"
QUERY: "will consider" or "must consider"
b. para starting "A conformant application"
Delete
A conformant application
Replace
A conformant XTM processor
c. para starting "A conformant application"
QUERY: the paragraph ends "equality:"
Seems like paras 2 and 3 were meant to be
joined, with the trailing colon in para 2
leading into the bulleted list after para 3,
but I hesitate simply to rewrite without
being clear on your intent.
d. para starting "section 6"
Delete
equivalent
Replace
equal
** Hmmm... The section heading says "equality." Para 2
mentions "determining equality". Yet here
we have "equivalent". And below, in bullet one,
we have "may decide URN equality based on the URI
equivalence rules."
If all this is really the right verbiage, I am content,
but even so, a little explanation on the distinction
between equality and equivalence in this, er, context
might not go amiss.
Delete
in which
Replace
of how
Delete
to schemes that
Replace
to URI schemes that
QUERY: Sort the list for easy scanning? There is no
question of order of presentation here.
Delete
urn (RFC 2141),
Replace
urn (RFC 2141):
(Introduce a bulleted list with a colon)
QUERY: RFC 1738 is not in Annex A references. Should it be?
Delete
MUST
Replace
must
Delete
MAY
Replace
may
(See 4.1, "these words do not appear in all uppercase letters
in this specification.)
F.2.3 Scope equality principle
a. para starting "if the"
Delete
If the topic map
Replace
In a consistent topic map,
(Obsessive attempt to use exact glossary phrase.)
Delete
two scopes may be considered equal
Replace
a conformant XTM processor may consider two scopes equal
Despite my reverence for the passive voice, it seems reasonable
that we be clear that it is, in fact, a conformant XTM
processor that is doing the "considering."
F. 2.4 Association equality principle
a. para starting "two associations"
Delete
Two associations are considered equal
Replace
** A conformant XTM processor must consider two associations
to be equal
Not only can we use the active voice, we can enforce the
requirement.
b. list item 1
QUERY: I cannot come up with an alternative to "consist of"
there being no Roget at my Paris site. However, I object
to "consist of" because an association does not merely consist
of roles. So, taken literally, item 1 can never be true.
c. list item 2
** QUERY: Do the merging rules affect the wording of this
rule? If the associations are equal, then the topics will
have merged into a single set (therefore not "are equal",
since the set is now singular). If the topics have not
been merged into a single set, then the associations
are not equal.
d. list item 3
Delete
of the same class
Replace
instances of the same class
e. QUERY: F2.4 requires a consistent topic map, 2.4 does not.
Is this OK?
F.2.5 Topic name equality principle
a. para starting "Two Names"
Confusing.
What is a "Name"? (Why the capital?) How is this different
from a base name or a variant name? Is the term meant to
subsume both? Or are there other kinds of names?
In fact, it must be base names by item 2 in the list, since
variant names lack scope.
b. item 1 starting "the string"
Delete
value
Replace
values.
c. item 2 starting "the scopes"
Delete
valid
Replace
occur
F.2.6 Topic occurrence equality principle
a. para starting "Two"
Delete
Topic Occurrences
Replace
topic occurrences
b. list item 1 starting "the URI"
Delete
URI
Replace
URIs
Delete
data values that are the occurrences
Replace
data content of the occurrences
(On first reading, I didn't see that the resourceRef
resourceData distinction was at work here, and "content"
flags this for me -- #PCDATA not a "value".)
b. list item 2 starting "the topics"
Delete
defining the nature of
Replace
of which the occurrence is a class (if any)
(Don't know what "nature of" means outside of the
er, context, or roleSpec where I don't like it
all that much either.)
c. list item 3 starting "the scopes"
Delete
in which the occurrences are valid
Replace
of the occurrence
(Valid seems awfully strong for what is, after all,
just a topic characteristic.)
F.3 Equivalence principles
a. para starting "equivalence principles"
Delete
"and process them ... used."
** I don't see why this is a good thing. For example, suppose
there is a user requirement to have an XTM document output
from the processed topic map constructs -- aren't there
cases where it would be useful to know the source of the
processed construct? I don't see the reason why this
is a CONFORMANCE requirement. Why should an XTM application
be REQUIRED to brush over its traces in this way?
Further,if the syntactic representation is "indecipherable",
then presumably there is some representation that the
processor finds "cipherable"? Is it the topic map node?
A topic map construct? What is it? This seems a missing
piece to me ... I will label the missing piece the "plane
of abstraction."
If the phrase is not deleted, please try something like
deleting:
indecipherable
replacing
undetectable
Delete
a topic map construct
Replace
topic map constructs, as listed in this section.
b. para starting "equivalence principles"
** QUERY: please define "topic map construct." If there
are "topic map constructs" that are distinct from
"topic map nodes", what are they? Otherwise, we
have equivalence principles, but the "thing" that
is equivalent is not known.
F.3.1 Equivalence of <subjectIndicatorRef> and <topicRef>
a. para starting "A <subjectIndicatorRef"
delete
which (2 cases)
replace
that (2 cases)
** COMMENT: I don't know what "defined by" means here. Is it
the case that the <subjectIndicatorRef> and <topicRef>
reify the same addressable subject? (So far as I can
see, the only place where topics "define" anything is
in the "Gentle Introduction", and that is far less
formal than the rest of the spec.
This again goes to the issue of the missing "plane"
in which topic nodes have their being and presumably
their equivalence. "Things" are defined somewhere,
but where "topic A" is being defined is left open
in this Annex.
** The levels of abstraction in this paragraph are not clear
to me. What is "topic A"? Is is a topic node? Is it a
topic map construct? Is it a <topic> element? Is it the
concept (dread word) of a topic? (No, since that would
be an instance of the class Topic with a capital T).
How do I reconcile the knowledge that the referencing is
done with a URI with a construct like "topic A"?
b. second para starting "A <subjectIndicatorRef"
** COMMENT: This paragraph, and several others in the Annex,
contains the phrase "subject indicator resource"
I state again my uneasiness with "the loss of the
distinction between subject constituting and subject
indicating resource. I note further that this Annex
seems to find the distinction useful. See, eg, section
F.5.1.
Note also how easy it is to talk about equality and
equivalence when you have the concept of "subject
identity point" -- since "two things can't be in the
same place at the same time," topics with the same
subject identity point are merged.
** Again, the meaning of "defined" is not clear to me.
See immediately above.
F.3.2 Equivalence of <instanceOf> and <association>
a. para starting "an <instanceOf>"
** COMMENT: See comments above on levels of abstraction
(search up on "topic A"). There, we had, "topic A".
Here, we have "<topic>, T". Which is it, or is it
some abstraction that subsumes both?
** COMMENT: See comments above on "defined". Where is
this relationship defined. Not in the syntax itself,
but there is no other place available.
The above comment applies to all usages of "defined".
So there will be no more such comments ;-)
b. para starting "This relationship may be"
** COMMENT: We have the phrase "the player of the
Class role is the topic T." But we have no
plane of abstraction on which roles may be played.
I don't believe it is enough, in a Processing Requirements
document, to say that "the player of a role ... is the
topic which reifies". Check the glossary definition
of reification -- "create a topic". In the, heck, context,
of a processing model, when I "create", do I create
a topic node (in the glossary), a topic map construct
(in this Annex)?
c. para starting "an <association>"
In the sentence 'If an <association> is used to
define a "Class-Instance"'
QUERY: Is there a word or phrase missing after
"Class-Instance"?
** QUERY: The paragraph immediately above contemplates
an "association". This paragraph speaks only of
"<association>". Are both right?
If not, does the distinction need to be explained?
If "association" is in fact correct in both places,
do items 1-4 apply to associations?
d. list item starting "4. Either"
** Suppose I merge two topic maps using a <mergeMap>
element and the <mergeMap> element adds scopes
to the <association>s in the merged topic map
(which it will under F.5.4.D).
Now I get errors on all the <association>s in
the map that I added the scopes to.
F.4.1 Variant scope processing
a. para starting "The scope"
Delete
scope
Replace
processing context
Delete
and its ancestor <baseName> element.
(The explanation for this change in para 2 does not require
the final phrase deleted above.)
F.4.2 Variant errors
a. para starting "It is a reportable XTM error"
First, this points up a discrepancy between the prose
content model and the DTD.
PROSE:
<!ELEMENT variant ( parameters, variantName, variant* ) >
DTD:
<!ELEMENT variant ( parameters, variantName?, variant* ) >
** Second, unless I'm missing something, we could enforce this
requirement using the content model, so why don't we just bite
the bullet and do that, if indeed the requirement exists? (I
say "if" because I think the change to variant was made after
this Annex was written.)
<!ELEMENT variant ( parameters
, ( ( variantName, variant*)
| variant+
)
)
>
Using this approach, this entire section could be deleted.
F.5.1 Topic merge operation
precondition
LOVE the precondition/postcondition format. Great work, great
addition, crystal clear, couldn't possibly say enough nice
things.
** "topics, A and B" -- again, the plane of abstraction on
which the merging takes place is unclear. Are these "topics"
nodes? Constructs?
postconditions
1. Add trailing period
5. Delete
Play in any roles
Replace
Player of any roles
7. Add trailing period
Error condition
a. para starting "It is"
** QUERY: Isn't it the case that if the Postconditions are
clear and complete, then no error conditions are necessary?
To put this another way, is it ever NOT an error if a
postcondition is not true following the operation,
given that all the preconditions are true?
And, if it is possible for a postcondition to be false
without creating an error condition, then what is the
purpose of the postcondition in the first place?
1. delete
resources or
replace
resources, or
BUT, given the query immediately above, why not rephrase
the error condition as a precondition
2. If either topic A refers to a subject constituting
resource R1, and topic B refers to a subject constituting
resource R2, R1 must equal R2. [WARNING: check my use of equal
against your vocabulary.]
2. The same comment as above applies -- the error condition
can be rephrased as a precondition, especially since you
have these powerful equality/equivalence tests to do
the job. Therefore a new precondition:
3. If topic A refers to association C as a subject
indicating resource, and topic B refers to association
D as a subject indicating resource, then C must equal
D in terms of association equality.
Example:
COMMENT: I love having the examples, this again is totally
great and many thanks.
However, I'm uncomfortable without that "plane of abstraction."
Here, my discomfort is that the only "output" of an XTM
conformant processor (not that we speak of "output") is
implied to be XML.
First, if as in F.3 we have made the syntactic representation
"indecipherable," are we really sure we can get "the same"
outputs from our inputs? For example, if we merged two identical
topic map documents, and then merged <topic>s as under this rule
F.5.1, do we know, for example, that <topicRef>s wouldn't be
replaced by equivalent <subjectIndicatorRef>s, and so on?
Second, by implying that our only output is XML, we cut
ourselves off from connecting to databases for example
through our (missing) "'back' :-) plane of abstraction.
In other words, presumably TMQL is querying something --
is it querying just the markup? If not, it is querying
the missing plane of abstraction.
F.5.2 Subject-based merge operation
a. para starting "two topics"
delete
the topic map
replace
topic map M
1,2,3
delete trailing
or
replace trailing
, or
(Much easier to spot for me. I missing them the first time. You
might
also consider moving the trailing "or" to lead the next paragraph,
to make the boolean alternatives even easier to spot.)
2. QUERY
delete
or
replace
(or vice versa), or
3,4. delete
there exists
replace
there exist
However,
Since the initial condition in 3 and 4 is the same ("there
exists [sic]
... topic B"
Consider combining steps 3 and 4 into a single step three with
substeps
for the alternative applications of the equality principles.
This
will make the dependencies a lot easier to spot.
Postcondition
1. delete
according to the Topic Merge Operation
replace
with pre and post-conditions as specified
by the Topic Merge Operation.
(Since "according to" can be nothing but the specified
conditions, let's just say that.)
Add postcondition 2:
2. Topic map M is a consistent topic map.
F.5.3 Topic naming constraint-based merge
a. para starting "two topics"
delete
the topic map
replace
topic map M
precondition
1,2,3,4 QUERY:
Add
trailing "and, " to steps 1-3, and trailing period to step 4.
Postcondition
1. delete
according to the Topic Merge Operation
replace
with pre and post-conditions as specified
by the Topic Merge Operation.
Add postcondition 2:
2. Topic map M is a consistent topic map.
F.5.4 Explicit merging of external topic map documents
precondition
1. delete
element is processed
replace
element is processed in Topic Map M
delete
which
replace
that
2. QUERY: delete
The <mergeMap> element contains references to a set
of subjects S by means of its optional, repeatable
child elements.
replace
The children of the <mergeMap> element reference
a set of subjects S.
(The set could be the empty set -- if the * turns out
to mean 0 children. So no need to mention childen.)
postcondition
1. delete
are added
replace
is added
delete
with the scope ... and the set S.
(See comment on invariant below.)
** Add invariant
2. Topic map M is a consistent topic map.
Why? (1) Because precondition 2 refers to the children of
the <mergeMap> element, which will not reference a
set until all duplicates have been removed.) (2) Now
there is no need to specify any other merging rule in
the topic map merge -- the invariant handles it.
F.5.5 Implicit merging of external topic map document
** DELETE
I think the definition of "consistent topic map"
covers this case elegantly with the wording
"no futher opportunities for merging." Section
5.5 covers what to do when there ARE such further
opportunities. So why do it?
"has not yet been processed" also worries me -- it seems to
contemplate that all topic maps are processed in a linear
fashion. What would "yet been" mean in LINDA space, or in a
context of parallel processing?
F.5.6.1 Subject indicator resource duplicate suppression
preconditions
1. delete
the topic map
replace
topic map M
QUERY: Don't these duplicates just get merged under the
subject based merging rule? Why delete them here? If this
is an issue of storing 2 URI references, or not, is that
not application specific?
2. Add trailing period.
postconditions
1. "removed from A"
COMMENT: In the absence of a plane of abstraction, and lack of
knowledge
as to whether A is a node, a construct, or some third thing,
the meaning of "remove" is unclear.
Add postcondition 2:
2. Topic map M is a consistent topic map.
F.6.2 Topic name duplicate suppression
preconditions
1. delete
the topic map
replace
topic map M
delete
which
replace
that
add trailing period
Consider swapping "basename ... that contains
a basename string ... in scope ..." with "basename
... in scope ... that contains". The basename contains
the string no matter what scope it is in. Or at least
sthe basename *element* does.
postcondtions
1,2,3,4 Add trailing periods.
2,3 Does the "are added" imply merging parameter contexts?
5. QUERY: Delete? Seems application specific.
COMMENT: Note, again, that in the absence of the plane
of abstraction, I cannot tell where the names "are created",
how they "are added", and where they "exist".
Add postcondition 6:
6. Topic map M is a consistent topic map.
COMMENT: If the topic-basename association is implemented
as an association between nodes, then normal merging
operations take care of this section, and it is not
needed.
AND HERE IS WHERE I HAD TO STOP GIVEN THE DEADLINE.
=====
<!-- "To imagine a language is to imagine a form of life."
- Ludwig Wittgenstein, Philosophical Investigations -->
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/
------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/337252/_/981573247/
---------------------------------------------------------------------_->
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