[sc34wg3] XTM 1.1 issues: MergeMap
Lars Marius Garshol
Tue, 13 Dec 2005 21:00:14 +0100
* Mason, James David
> I can see how you consider it an authoring issue, but I don't see
> that as being in conflict with an interchange syntax.
Well, if you take a strict view of what "interchange syntax" means
that to me really implies "format that allows model instances to be
moved from A to B". So any features that are not necessary for this
(like <mergeMap>) would not go in if the XTM 1.0 requirements were
> 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.
Yes, I think this is a quite common user requirement. I think that
requirement really is indicative of a failure of the tools to allow
users to move beyond a module == file way of thinking and instead
into one where they can create modules when they want them. (This is
what's behind my latest blog entries on fragments.)
However, I think we have to recognize that we are where we are, and
this is a feature we had in 1.0. This makes it hard to remove it in
1.1 if there are people who really want it, and I doubt very much
that you are alone in wanting this.
The editors have discussed this back and forth quite a bit, but
eventually fell down on the side of keeping <mergeMap/>.
> Part of my practice goes back to SGML days, when I had modular DTDs
> and modular documents.
I could write a lot about how I think SGML was bad for people in that
it made them think too much in terms of files, and how it's hurt both
XML and Topic Maps, but in one sense that's really not the point.
People want this, and one of the reasons they want this is that the
tools aren't good enough yet. I can live with that (and try to change
the tools so that *next* time... :).
> 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.
Simple and consistent it is, once you remove the added themes. This
is why the editors feel they can live with it, even if it does make
things more complex.
> 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.
I think the name is fine. It's more the complexity, and the question
of what XTM is really meant to be. I always felt that the presence of
this feature (and inheritance of scope on nested <variant>s, and the
omissibility of role players) were really violations of the original
requirements. Changing the name doesn't change that. :)
Lars Marius Garshol, Ontopian http://www.ontopia.net
+47 98 21 55 50 http://