[sc34wg3] Removing added scope from <mergeMap>

[Mason, James David (MXM)]

A couple of points:

I don't see merging/modularization/module management as "authoring" =
issues. I
see them as central to the whole TM system, perhaps more important than =
the
data model. From that perspective, I think we need to take care of them
*before* we settle the data model. We aren't doing just data.

I don't see processing -- including merging -- as separate from =
interchange.
If we were just shipping bits around, interchange could be simple. But =
the
initial premise of TMs is that we're shipping more than bits; we're =
shipping
ideas. And when you're dealing with ideas, processing is very important.

There's one side of me that doesn't care what solution comes out of this
discussion: just give me some schema that does the job and some =
assurance
that software will support it, and I'll go away. But before I settle on =
such
a carefree attitude, I come back to the side of me that says, "don't =
break
the system". I'm still hearing from people who have large quantities of
legacy data in SGML and aren't ready to convert it to XML (I moderated a
panel in Atlanta that involved that question). I don't have monstrously =
large
amounts of data in XTM 1.0, but I don't want to go to something new =
unless I
have reasonable assurances that there are migration tools (is it going =
to
take more than 10 minutes hacking an XSLT script?). We shouldn't make
backwards compatibility an absolute stumbling block: Goldfarb did that =
with
SGML, and that's one reason the XML team moved out of SC34. But we =
shouldn't
treat it casually. I know that a lot of the folks in WG3 throw their TMs
together in syntaxes like LTM, but users who have actually been =
developing
TMs are more likely to be using XTM because it is, at least, a standard. =
So
we shouldn't just ignore backwards compatibility, tossing out features
because they don't conveniently fit some abstract model: maybe the =
model's
wrong.

In short, if a model doesn't deal with the issues involved in merging, =
etc.,
then it isn't an adequate model, and we shouln't progress it.

If an interchange mechanism doesn't cover the functionality we already =
have,
likewise we shouln't progress it.=20

But I'm open to suggestions as to how we can encode, interchange, and
reassemble content (as opposed to data).

Jim=20