[sc34wg3] XTM 1.1 issues: MergeMap
Mason, James David (MXM)
sc34wg3@isotopicmaps.org
Mon, 12 Dec 2005 13:58:46 -0500
This is a multi-part message in MIME format.
------_=_NextPart_001_01C5FF4E.14BACCE1
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
I was not in on all the discussions in Atlanta, so I don't know what was =
said
there about this subject:
=20
--- <mergeMap>
Another question is whether the <mergeMap> element really belongs in
an interchange syntax. The capability for merging topic maps is useful, =
but
the act of doing so is really an act of authoring, and putting =
<mergeMap> in
the syntax is really putting authoring features in the syntax.
The alternative is to say: which files get loaded depends what the
user told the processor to load. The user can choose to load 1, 5, or
17 files into a single topic map.
=20
I can see how you consider it an authoring issue, but I don't see that =
as
being in conflict with an interchange syntax. My TM projects typically =
draw
on many sources, and so may have dozens of individual TM files. I =
typically
generate XTM from XSLT scripts (lots of sources, lots of scripts, each =
script
doing a particular kind of thing to a source to generate a particular
module). I want to be able to keep the modularization of my TM =
components and
have some sort of "hub document" (to use HyTime terminology) to pull =
them
together.
=20
Part of my practice goes back to SGML days, when I had modular DTDs and
modular documents. The SGML mechanisms (e.g.., entity declarations, =
followed
by entity references or CONREF or application-specific use of =
attributes) are
somewhat clumsy and not entirely well defined in the standard, so I =
liked
this individual usage that was at least simple and consistent. SGML was =
also
intentionally an interchage syntax, but we didn't see supporting =
authoring
conventions as being orthogonal to that function. (I don't want to =
reopen the
whole can of authoring worms that we built into the language -- save =
that for
Extreme.)
=20
I can easily be persuaded that <mergeMap> should be renamed; it's an =
entirely
different use of "merge" from the merging of topics that is central to =
the
topic-identity discussions.
=20
Jim Mason
=20
------_=_NextPart_001_01C5FF4E.14BACCE1
Content-Type: text/html;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2769" name=3DGENERATOR></HEAD>
<BODY>
<DIV><!-- Converted from text/plain format --><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>I was not in on all the discussions in Atlanta, so I don't know =
what was=20
said there about this subject:</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><FONT size=3D2>
<P><FONT color=3D#000000>--- <mergeMap></FONT></P>
<P><FONT color=3D#000000>Another question is whether the =
<mergeMap>=20
element really belongs in an interchange syntax. The capability for =
merging=20
topic maps is useful, but the act of doing so is really an act of =
authoring,=20
and putting <mergeMap> in the syntax is really putting authoring =
features in the syntax.</FONT></P>
<P><FONT color=3D#000000>The alternative is to say: which files get =
loaded=20
depends what the user told the processor to load. The user can choose =
to load=20
1, 5, or</FONT></P>
<P><FONT color=3D#000000>17 files into a single topic=20
map</FONT>.</P></FONT></FONT></DIV></BLOCKQUOTE>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>I can see how you =
consider it an=20
authoring issue, but I don't see that as being in conflict with an =
interchange=20
syntax. My TM projects typically draw on many sources, and so may have =
dozens of=20
individual TM files. I typically generate XTM from XSLT scripts (lots of =
sources, lots of scripts, each script doing a particular kind of thing =
to a=20
source to generate a particular module). I want to be able to keep the=20
modularization of my TM components and have some sort of "hub document" =
(to use=20
HyTime terminology) to pull them together.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Part of my practice =
goes back to SGML=20
days, when I had modular DTDs and modular documents. The SGML mechanisms =
(e.g..,=20
entity declarations, followed by entity references or CONREF or=20
application-specific use of attributes) are somewhat clumsy and not =
entirely=20
well defined in the standard, so I liked this individual usage that was =
at least=20
simple and consistent. SGML was also intentionally an interchage syntax, =
but we=20
didn't see supporting authoring conventions as being orthogonal to that=20
function. (I don't want to reopen the whole can of authoring worms =
that we=20
built into the language -- save that for Extreme.)</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>I can easily be =
persuaded that=20
<mergeMap> should be renamed; it's an entirely different use of =
"merge"=20
from the merging of topics that is central to the topic-identity=20
discussions.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2>Jim Mason</FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT> </DIV></BODY></HTML>
------_=_NextPart_001_01C5FF4E.14BACCE1--