[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xtm-wg] Comments on XTM Spec 1.0
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC