OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[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