[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] XTM Requirements: Possible Extensions to ISO13250 to consider
-------------------------- eGroups Sponsor -------------------------~-~> Free @Backup service! Click here for your free trial of @Backup. @Backup is the most convenient way to securely protect and access your files online. Try it now and receive 300 MyPoints. http://click.egroups.com/1/6348/4/_/337252/_/968153208/ ---------------------------------------------------------------------_-> OK, so my example for number (2) was not that hot. But maybe the requirement still holds. (I'm considering a career in greased eel juggling instead ;l ) Peter -----Original Message----- From: Peter Jones [mailto:peterj@wrox.com] Sent: 05 September 2000 10:54 To: 'xtm-wg@egroups.com' Subject: [xtm-wg] XTM Requirements: Possible Extensions to ISO13250 to consider Hi, Over the weekend I finally got around to reading AnnW's excellent use cases. I also managed to devote a small amount of time to thinking about how they (and a use case I suggested) might be implemented. From this thinking two intuitions arose -- and I stress that they are just intuitions at this time. (I apologise if these issues have precendents raised by others like HH Rath and Steve Pepper that I have not had time read yet.) 1) Not being familiar with HyTime in any depth could someone who is tell me whether it is possible to have an association or topic in which it is possible to specify an aggregate link in which some of the link ends are specified as bi-directional and some are specified uni-directional? I.e. within an assocrl, specify which topics are uni-directional link ends and which are not? Anyone with the relevant experience know if this would be a bad idea or not? 2)In ISO 13250 the semantics of scope is rigidly defined, but only one semantic model is used -- namespace-disambiguation. I wondered whether it might make sense (outside of the use of TMs in merging indexes) to define several different semantic models for the scope, e.g. superclass-subclass inheritance of scope names; set-member relations between scope name sets; and to be able to indicate which model is being used where -- whole TM, parts of TM, etc. For instance, if I want to use TMs to serialize multiple instances of an application (including the states of all objects) into one TM, then at the very least the set-member semantic would be useful. So at the top level I would have scope = "ObjectSet1" and for each resource link in the link set have, e.g., 1-scope = "ObjectSet1-Object1", 2-scope = "ObjectSet1-Object2", and so forth. Anyone with the relevant experience know if this would be a bad idea or not? HTH, Peter To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 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