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: 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