[xtm-wg] XTM 1.0 Comments

["Kal Ahmed" <kal@ontopia.net>]

These are collected comments from Ontopia.


SYNTAX SPEC COMMENTS
--------------------

4.7.1 - baseName
The XTM name syntax is structurally different from the ISO 13250 name syntax
and a mapping between them needs to be defined. The main problems are:
1) ISO 13250 <topname> allows multiple <basenames>
2) ISO 13250 has the concept of scope only, not of parameters too

There needs to be some form of mapping defined - probably via the Conceptual
Model. But it might also be useful to have prose (non-normative) text which
describes how to achieve the mapping in XTM->ISO syntax terms.

We believe that a mapping such as the one proposed should be specified in a
Topicmaps.Org document (although not the XTM 1.0 specification).



4.7.2 - baseNameString
replace:
The <baseNameString> element is a string that represents the base name of
its ancestor <topic> parent.
with:
The content of the <baseNameString> element is a string that represents the
base name of its ancestor <topic> parent.

4.7.3 - variant
What is the significance of unlimited nesting of variants ? Is this being
used to create a 'processing context' tree for device dependant resources ?
If so we believe that the responsibility for content negotiation (selecting
the correct representation for the target device) should be the
responsibility of the resource rather than of the topic map. If there is no
other reason for nested <variant>s we propose removing <variant> from the
content model of <variant>

4.7.5 - parameters
There appears to be some inconsistency in the use of <resourceRef>. If
<resourceRef> is an allowed part of the content model for <scope>, why is it
not allowed in <parameters> ? Is there some difference between a topic in a
parameters list and a topic in a scope ? If so can this be explained please.
If not, we propose adding <resourceRef> to the content model of <parameters>

Additionally, we would like to see some guidance as to what constitutes a
'processing context' as opposed to a 'topic characteristic assignment
context'. For example, can <parameters> be used to express the language of a
particular variant (in other words is language considered to be a valid
'processing context' parameter ) ?.



4.8.2 - member
<member> should still be named <associationRole> for consistency with ISO
13250 terminology, unless some very convincing reason can be given for the
new term.



4.9.1 - occurrence
The reference to the class of occurrences to which the <occurrence> belongs
should have the already standardized ISO terminology of "role" instead of
<instanceOf>.

<occurrence> should not have an optional <baseName> child. Reification
can be used to do this. The really disturbing effect of <baseName> is that
the the a-node representing the occurrence could be merged with another
a-node or t-node by the topic naming constraint. We do not believe that this
is an intended or desirable effect of naming occurrences. It also seems
inconsistent to have <baseName> here and not on <association> (given that
Occurrence is a specialisation of Association).

At the Dallas meeting that there was a formal vote specifically AGAINST
having baseName on occurrence on the grounds that reification could and
should be used instead.

NOTE: I, personally, feel that this is also an argument against the
inclusion of the topic naming constraint in the XTM processing model. But
this is covered in a separate thread.

We propose that <baseName> be removed from the content model of
<occurrence>.



PROCESSING SPEC COMMMENTS
-------------------------

General comment:

We feel that the Processing Model is far too constricting on applications.
We believe that XTM processing requirements should be stated as a set of
operations which a conformant application is required to support and the
pre- and post-conditions for those operations. A conformant topic map
application should not be required to build the graph structure defined in
the Processing Model, nor should it be required to remove the option from
the user of not processing all inputs to the topic map graph (specifically,
an application - especially in a web environment) should not be required to
locate and merge many different topic maps if the user does not want it to.
We also strongly believe that a user of a conformant topic map application
should not be required to pay the price of visiting every topic element or
potential topic element referenced from a given topic map - in a world of
pay-per-view information, such a requirement could imply a direct financial
cost as well as a time and bandwidth cost.

A first stab at such a list of operations would include:

The merge operation.
Determining a merge by subject identity
Determining a merge by topic naming (if it is to be kept)
Processing mergeMap directives
Processing references to topics in other topic maps
Determining equivalence of subject constituting resources
Determining equivalence of subject describing resources

Some requirements which should also be specified:
Equivalence of <instanceOf> and the class-instance association
Equivalence of <occurrence> and the topic-occurrence association
Other such equivalences.
Requirements for determining string equivalence (for the topic naming
constraint).


Note that I feel that only a definition of equivalence is required. Exactly
how an application supports that equivalence should not be defined.

I have probably missed plenty of things out here, but this is to give a
flavour of the kind of approach we would find preferable.

Ann Wrightson has also pointed out to me that:
"In the context of  TMQL, is is very important that the XTM processing model
only
specifies as much as is necessary to *establish a persistent topic map*. We
don't want an XTM processing model pre-empting or encroaching on TMQL. The
approach TMQL needs to take here IMO is that any app may establish a topic
map
according to its own processes - but then, TMQL can apply in full thro the
app's
TMQL interface."


1.3 Terminology

XTM SPEC: "unconstrained scope - The scope comprised of all of the topics in
a topic map."
XTM PROC MODEL: "unconstrained scope, the - The scope that consists of no
topics; the null set."

Which is it ? Our view is that if a topic is in the unconstrained scope, its
scope of validity is just that - unconstrained. In other words, regardless
of my application's view of the topic map (the 'application scope'), topic
characteristic assignments in the unconstrained scope are always valid. If
this is not the case, then the scoping of basenames has serious implications
for processing software & user-interfaces.




2.3.1 The Subject-based Merging Rule

The minimal rules for determining when two resources are the same need to
be spelled out.  The few rules given in the specification are not complete
and will lead to interoperability problems. Some issues which must be
addressed:
 - case-insensitivity of host names
 - defaulting of port number
 - the percent escape rules
 - absolutization
 - http redirects (we believe that they should NOT be taken into account)
 - Scheme-specific lexical equivalence rules (we believe that these should
not be taken into account either)

We propose that something simple and achievable should be mandated so that
it is assured that all XTM conformant implementations will interoperate.



2.3.2 Topic Naming Constraint-based Merging

I have a strong objection to this rule which is detailed in a separate
posting.
However, we also note that the phrase  "and the strings (the "basenames")
match each other" is ambiguous. Specifically, what is the kind of matching
which a conformant application is required to apply ?



2.3.4 Node Demanders

The phrase "node demander" requires clearer definition. For example, a
<scope> element contains a <subjectIndicatorRef> element which causes the
generation of a t-node. It must be the case that it is the
<subjectIndicatorRef> element which is regarded as the node demander rather
than the <scope> element. The latter would cause unpredicatble collapse of
topics through the merging rules.

We think it would be clearer to enumerate the node demander element GIs.

Additionally, what is the subject indicator reference for an automatically
generated t-node when the node demander has no ID attribute value ? We
assume that no subject indicator value is required.



2.4.2 <topic> Elements and their descendants

<subjectIndicatorRef> in <subjectIdentity> should not cause the containing
topic to be merged at all. <topicRef> already causes this to happen and is a
useful tool for forcing a merge to occur, but it seems unnecessary to extend
this semantic to <subjectIndicatorRef> - it would make <topicRef> redundant.
Additionally, in a distributed environment, the requirement that a
processing application chase down every <subjectIndicatorRef> to determine
whether or not the referenced resource is a <topic> element is a highly
burdensome constraint.

Similar arguments apply to the handling of the <topicRef> element
We believe that in order to provide users with full control over the
acquisition and merging of topic maps an application should not be required
to retrieve and process the <topic> element indicated by a <topicRef>
element, such processing should instead be specified but optional.



To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com