[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xtm-wg] XTM processing model issues
I said I would provide some comments on the XTM Processing Model document. My main concerns are two: 1) The XTM processing model document states: "The XTM Processing Model requires that a topic map graph be constructed from a <topicMap> element, before any other processing is done." I believe this constraint is out of place. It places an unnecessary limitation on applications. "Lazy" processing *must* be allowed if TM applications are not going to be grounded by performance limitations. What needs to be specified is what the meaning of the information carried by an XTM instance is - not *how*, and still less *when*, an application must derive that meaning from the structure and cpontent of the instance. 2) I am concerned that the descriptions of t-nodes, a-nodes, s-nodes etc are more about implementation than about meaning of information. I do not believe we should be standardising any particular implementation approach. What we do need to do is explain rigorously how the syntax maps to the conceptual model, particularly where there is not a one-to-one correspondence between the constructs in each. This will include specifying the "merging rules" that determine when multiple elements in XTM instances represent a single topic, association, role etc. It will also include specifying what constraints result when an association is stated to be derived from an association template. But those constraints should not be described in terms of what should exist in the system after processing. Rather, it is a constraint on the information set itself. For example: if I have a template for marriage where the class of permitted players of the role "husband" is the "man" class, this means that there must exist a class-instance association between the husband in the marriage and the class of men. My XTM instance may or may not make that association explicit. If it is not explicit in my instance, I may wish the application to signal to the user that there is doubt as to the player of the role husband because he is not stated to be a man, or I may wish to allow the appication to infer that he must be a man and create the association automatically. These are application-dependent issues. The meaning of the information is what we should be stating in the specification, not the processing details or processing sequence. Having said this, it can be very useful to describe a processing model as an informative example of a possible and legitimate approach. My concern is that we should not state that using this processing model is a condition of XTM conformance. Such a description of a processing model should not be part of the XTM Specification itself, unless it is explicitly stated to be "informative" rather than "normative". On the other hand, I believe we do need a *normative* but *processing-neutral* description of the merging rules and template constraints, and I believe this has not yet been written. Do others have views on this? Best regards Daniel -------------------------- eGroups Sponsor -------------------------~-~> eLerts It's Easy. It's Fun. Best of All, it's Free! http://click.egroups.com/1/9699/0/_/337252/_/977248370/ ---------------------------------------------------------------------_-> 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