[sc34wg3] <mergeMap/> and security

[Mason, James David (MXM)]

1. I believe that the potential for malicious use of <mergemap> -- or any
other component of an interchange standard that has otherwise legitimate uses
-- is not an excuse for dropping it from the standard. There are far more
serious risks in the whole business of information interchange as a result of
providing misleading or even malicious data for almost any component of the
interchange data stream than are afforded by this one element. There are
sufficient means for malicious use of SGML/XML at the basic level at which
they have been standardized over the past two decades that the current
argument seems like straining at gnats. 

Furthermore, issues of network loading, evasive URIs, etc., are outside the
scope of 13250 and, indeed, outside the scope of SC34 and so should not be
considered in the discussion of revision of 13250. The discussion of such
matters belongs in SC6, SC27, the W3C, or the IETF. Unless presented with
some overwhelming evidence to the contrary, I rule further discussion of this
matter out of order.

2. The accusation that <mergemap> is merely an authoring convention is
spurious and evasive. As a creator and consumer of TM content, I find the
functionality necessary for my use of 13250. I cannot separate authoring from
the facilities available for interchange. For a variety of reasons, it is
difficult for me to interchange fully resolved TMs, which would be the result
if this functionality were removed. (In short, with mergemap, it is possible
for me to interchange unclassified fragments of documents that would be
classified in a fully resolved case.)

3. Removing this functionality would break ALL my working TM projects.
Updating standards in such a way that it removes backwards compatibility is
discouraged. There may be better ways of implementing the functionality, in
which case current usage might be deprecated, but it should not be removed
outright. Certainly it should not be removed or even deprecated without
providing a path forward for current users.

Items 2 and 3 have been sufficiently hashed over in earlier discussions that
I don't see much good will come of bringing them up again.

Jim Mason
Chairman, ISO/IEC JTC1/SC34