[sc34wg3] Almost arbitrary markup in resourceData

[Mason, James David (MXM)]

Thanks, Martin!

This is my understanding, too.

This is why I also believe we should not make a sacred cow of XTM.

Jim

-----Original Message-----
From: Martin Bryan [mailto:martin@is-thought.co.uk] 
Sent: Monday, November 17, 2003 3:15 PM
To: sc34wg3@isotopicmaps.org
Subject: Re: [sc34wg3] Almost arbitrary markup in resourceData


Jim

> I'd like to hear more from Martin and the other two original editors 
> on
what
> they thought their goals were for TM interchange.

I can't speak for Michel and Steve, but I have always been firmly of the
belief that TMs should be architectures: i.e. that any elements that
declared itself in the DTD to conform to a particular TM construct should be
treated as a component of the topic map while any element that did not that
was embedded in the topic map would be passed straight through. (I saw topic
maps as components of documents rather than stand-alone only devices, but
that's another tale.)

You must remember we did not have the namespace can of worms at that stage.
All elements were part of the same namespace, but those flagged as
conforming to the AF were processed *in addition to normal SGML processing*
by being passed to an TM engine. (One of the things that was most
misunderstood about AFs was the way they gave you fragment processing
without needing to invent namespaces, but that's another and much longer
story. The demise of AFs will one day be recognized for the fact it is: a
setback for the industry.)

As far as interchange was concerned I saw two scenarios:

1) Interchange of maps between engines: If I sent my topic map to another AF
conformant engine it would display the contents for me according to its
local user interface, without having to perform any transformation on my
local DTD. This meant that local users would already know how to navigate
topic maps using their own paradigm, and would not be forced into seeing the
maps in the format I used at my installation.
2) Merging of maps: If I took TM data from two documents and merged them
together (either physically or logically) the computer would identify points
of overlap for me so that I could navigate from structure to structure. At
merge points names and occurrences from both sources would form a single
list.

Like you I presumed that, as we had SGML, I could use notation to pull in
any data of any format wherever PCDATA was allowed. Therefore I could have
pictures in my PCDATA by putting a relevant entity reference in my elements.
Again, this is one of the places where XTM does not have as much flexibility
as we had during our original design.

Like you I see no reason for the model to restrict what applications do. If
XTM wants to further restrict things for "the sake of interchangeability" it
should still be possible to use topic maps in more flexible ways for private
interchange. That's why I suggested a compromise that would a) allow users
to identify what type of processing might be required b) identify what
control mechanisms were used when creating the map (not to allow you to
revalidate it on receipt but to see if you have a capability that would
allow you to process the data on receipt). It's a compromise, but at least
it's more sensible than the one-size fits all approach of "plain text only".
(After all I can put <markup> in plain text as easily as the next HTML
application.)

Martin



_______________________________________________
sc34wg3 mailing list
sc34wg3@isotopicmaps.org
http://www.isotopicmaps.org/mailman/listinfo/sc34wg3