[xtm-wg] Comments on XTM Spec 1.0

["Hans Holger Rath" <hhr@step.de>]

Hi XTM-WG,

Please find enclosed my comments on the XTM Spec 1.0.

Cheers,
--Holger

=====================
Wording:
=====================

4.6.1 <topic> Element
...old...
A <topic> element specifies zero or more names and zero or more 
occurrences that are relevant to its subject. Names are declared by means 
of <baseName> child elements. Occurrences are specified by means of zero 
or more <occurrence> elements.
...new...
A <topic> element specifies zero or more names and zero or more 
occurrences that are relevant to its subject. Names are declared by means 
of <baseName> child elements. Occurrences are specified by means of 
<occurrence> child elements.

4.9.1 <occurrence> Element

REMARK 1: The wording of the "Notes" ("When, in an <occurrence>, ...
merged into a single topic node.") is very difficult to read
(sounds like ISO English :). I would appreciate it very much
if it could be re-formulated with easier English grammar constructs
and in shorter sentences (may also be caused by my lack of
understanding non "Simplified English").

REMARK 2: If I get the "Notes" right (after five times reading)
<occurrence> could use <topicRef> to point to an topic as 
occurrence and then some constraints apply. My point is, that
the content model does not allow <topicRef> as subelement of
<occurrence>. Is the model from or is the wording wrong?

=====================
Content Model:
=====================

4.6.2 <subjectIdentity> Element

REMARK: If we really do not want to have a mixture
of resourceRef with topicRef and/or subjectIndicatorRef
we should make this crystal clear by the content model.
I do not know what we want. I was just a little bit
confused by the "Issue: ..." comment.

...old...
<!ELEMENT subjectIdentity
     ( resourceRef?, ( topicRef | subjectIndicatorRef )* )
>
...new...
<!ELEMENT subjectIdentity
     ( resourceRef | ( topicRef | subjectIndicatorRef )* )
>

=====================
Example Text:
=====================

4.7.3 <variant> Element

REMARK: Example is not valid against content model of 
section "4.7.4 <variantName> Element".
=> Change example.

4.7.5 <parameters> Element

REMARK: Let example just refer to example of section
"4.7.3 <variant> Element".

=====================
Concept and Content Model:
=====================

4.8.1 <association> Element

REMARK 1: A couple of people - and I am one of them - stated
that association should have a name (<baseName>) and occurrences
(<occurrence>) as child elements. The answer to that request
was: reification. The is an appropriate solution but it is
nowhere described in the XTM spec. There is 
http://www.doctypes.org/xtm/syntax/reification-syntax.html
but *the* solution is not marked in the document.
=> Please add information about reification to the spec with
an example that shows how names and occurrences can be "assigned"
to associations.

REMARK 2: The current concept of association templates seemed to 
me to be not powerful enough. As I have already written in 
another email I miss control over the number of roles (minimum, 
maximum values), the scope of the assoc instances, and that the 
topics playing the roles in the assoc instance could be of 
direct or indirect subclasses of the role class.

Finally, I suggest to add topic templates following the
same declarative approach. Candidates are (copy from an other 
email):
- number and kind of topic names, 
- scope of names,
- number of occurrences of certain type,
- number and kind of names of occurrences,
- scope of occurrences, 
- association the topic instance has to play
a certain role in (e.g. every person in the map 
has to play the "person" role in the "birth" assoc).

REMARK 3: Daniel Rivers-Moore posted 2001/01/08 a proposal
for a new association content model which is complient to 
the processing model. I copy it here for easier reference.

<!-- association: Topic Association -->
<!ELEMENT association (associationSpec? , instanceOf* , scope? , (member+ | role+ )*)>
<!ATTLIST association id ID #REQUIRED >

<!-- associationSpec: Points to a Topic Serving as an Association Template -->
<!ELEMENT associationSpec (topicRef | subjectIndicatorRef )>
<!ATTLIST associationSpec id ID #IMPLIED >

<!-- member: Member in Topic Association -->
<!ELEMENT member (roleSpec? , (topicRef | resourceRef | subjectIndicatorRef )+ )>
<!ATTLIST member id ID #IMPLIED >

<!-- role: Role in Topic Association -->
<!ELEMENT role (roleSpec? , (topicRef | resourceRef | subjectIndicatorRef ) , player* )>
<!ATTLIST role id ID #IMPLIED >

<!-- player: Player of Role in Topic Association -->
<!ELEMENT player (topicRef | resourceRef | subjectIndicatorRef )>
<!ATTLIST player id ID #IMPLIED > 


First, a syntactical point: 
<!ELEMENT association (associationSpec? , instanceOf* , scope? , (member+ | role+ )*)>
should be written as
<!ELEMENT association (associationSpec? , instanceOf* , scope? , (member* | role* ))>
or as
<!ELEMENT association (associationSpec? , instanceOf* , scope? , (member | role )*)>


Second, why do we need <member> and <role>?
Just for backwards compatibility? If yes, I
recommend to define a clear model instead
of looking for backwards compatibility and 
ending up with a messy model. 


Third, can someone explain why <association>
needs both <associationSpec> and <instanceOf>?
Is this just for backwards compatibility reasons?
If not, could someone provide an example, please.
Also if not: Will it make sense that an assoc template
is an <instanceOf> a class? Especially if the
derived assoc is also an <instanceOf> a class.
Do we have to define some constraints that have 
to be fulfilled by the classes (e.g., derived
has to refer the same class as the template
or one of its subclasses? Or ???).

=====================

-- 
H. Holger Rath <holger.rath@empolis.com>
empolis Content Management GmbH
Technologiepark, Pav. 7, 97222 Rimpar, Germany
http://www.empolis.com/ -- mobile: +49.172.66.90.427
phone: +49.9365.8062.63 -- fax: +49.9365.8062.66

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

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