[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] XTM-ISS Mergemaps and relationship to XML Include
Daniel, My reading of the XML Include spec is that an application sitting above the XML Include layer receives a single info-set formed by a merging of the document infoset and the included infoset(s). Note that this is a merging of XML infosets and not a merging of topic map constructs. My suggestion was that by using XML Include for specifying which topic maps to merge, it would allow application developers to rely on the XML Include-aware parser to provide them with a single infoset which could then be parsed for topic map constructs (with merging of topics as appropriate). However, that suggestion does overlook the potential size of topic maps and in the discussions which produced Ontopia's comments on tmdtd-00-09-25.txt (http://www.egroups.com/files/xtm-wg/Interchange/XTM+-+The+Ontopia+Comments. htm), we looked at the different ways of specifying what topic maps should be merged. My feeling is that *when* the merging takes place, should be application-specific and that using XML Include might force applications to parse alot of data unnecessarily, so in balance, perhaps use of XML Include is not such a good idea. Cheers, Kal > -----Original Message----- > From: Daniel Rivers-Moore [mailto:daniel.rivers-moore@rivcom.com] > Sent: 09 October 2000 10:01 > To: xtm-wg@egroups.com > Subject: RE: [xtm-wg] XTM-ISS Mergemaps and relationship to XML Include > > > Kal > > Would following your suggestion below imply that implementations have to > actually *do* the merging, within the system? I think we need the > possiblility of "late binding", where the topics are only > actually merged on > an "as-needed" basis. For some implementations, it might make sense to do > the merging immediately and cache the result; for others, it > might make more > sense not to do any merging until some system or user calls on a piece of > information that requires the merging to be done. > > One reason for not merging except on a Just-In-Time basis, is of > course the > enormous size of some topic sets. > > The NewsML standard (approved last Friday by the IPTC) has the notion of > TopicSetRef which allows the inclusion of all Topics in a referenced > TopicSet to be included within the current TopicSet. This inclusion is > subject to merging rules, which are stated in the comments to the NewsML > DTD. But the DTD is also explicit that this merging need not be performed > physically by the system. What is the case is that the data means the same > as would be meant by the data that would result from the merging > having been > performed. In other words, the merging takes place at the level of the > conceptual model but not necessarily at the level of the syntactic model. > > This confirms that the structure of the syntactic model and the conceptual > model need not be identical. For instance, there may be two Topic > *elements*, each with its own Duid (ID attribute - "Document-unique > Identifier), which in fact represent the same *topic*, because > they have the > same FormalName within the same naming Scheme. > > One of the reasons I have been so silent on this list over the past few > weeks is that I've been under contract to the IPTC to complete the NewsML > specification in time for the DTD to be formally approved on Friday 6 > October in Amsterdam. That work is now successfully completed, and the DTD > unanimously approved by the IPTC membership at their face-to-face > meeting. I > shall now be concentrating on working with the other members of the CMS to > bring our work to an appropriate stage for the meetings in Swindon at the > end of this week. > > The NewsML DTD is available at > http://www.iptc.org/NewsML/DTD/NewsMLv1.0.dtd. I believe it contains many > useful syntactic constructs that could be useful for the ISS to consider. > > Kind regards > > Daniel > > > -----Original Message----- > From: Kal Ahmed [mailto:kal@ontopia.net] > Sent: 25 September 2000 10:56 > To: xtm-wg@egroups.com > Subject: [xtm-wg] XTM-ISS Mergemaps and relationship to XML Include > > > > I was interested in reading the discussions about xtm:mergemaps at the top > of the latest XTM DTD draft > (http://www.egroups.com/files/xtm-wg/Interchange/tmdtd-00-09-25%2Etxt). I > wondered if the use of XML Include (http://www.w3.org/TR/xinclude) had been considered as the processing model for this construct. It is (as the URL indicates) still in working draft stage at the moment, but what it allows for is the merging (their term...unfortunately) of multiple XML infosets. 'mergemaps' is going to be a necessary construct (I would go so far as to say that if it is not part of XTM, it will get added as proprietary extensions to XTM) and that potentially XML Include provides the framework for describing how that construct is resolved *prior to* any topic map parsing. The potential here is for a construct which is implemented by the parser - i.e. involves no extra effort on my behalf...a definite win in the XML world. Cheers, Kal 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 -------------------------- eGroups Sponsor -------------------------~-~> GET A NEXTCARD VISA, in 30 seconds! Get rates as low as 0.0% Intro or 9.99% Ongoing APR and no annual fee! Apply NOW! http://click.egroups.com/1/9331/4/_/337252/_/971087288/ ---------------------------------------------------------------------_-> 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