[sc34wg3] XTM 1.1 issues: MergeMap

[Lars Marius Garshol]

* 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  
taken literally.

> 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:// 
www.garshol.priv.no