[sc34wg3] <mergeMap/> and security

[Lars Heuer]

Hi Patrick,

[...]
> What do you think the "purpose of the "mergeMap" element [was] in the 
> first place?"

I think the mergeMap element was designed to ease the _authoring_ of
XML Topic Maps.

[...]
> And how do you see that as fitting into a notion of an "interchange" syntax?

> Note that I am assuming that by "interchange" we actually mean 
> "anonymous interchange," that is no further communication with the 
> source of the file is needed for me to use the file that I have been 
> given.
> That is it contains all the information necessary for me to make
> use of it. It does not, however, predetermine the use to which it may be
> put.

That is exactly my point of view. But as long as the mergeMap element
is in the syntax, the user needs to communicate.
IMO a user expects that a particular file is self-contained. But with
the mergeMap element inside the XTM syntax, a XTM document may not be
self-contained.
The user cannot put a XTM file on a USB stick and read it with a
laptop without an Internet connection if it contains a mergeMap
element. To ensure that she can read the XTM document under (nearly) all
possible circumstances, she has to open the XTM file and look if it
contains mergeMap elements (a XTM novice won't do that).

> With that observation, what is the purpose of the "mergeMap" element?

It may ease the authoring process but it puts definitely a burden on
the receiver of a XTM file.

*We* know that the usage of the mergeMap element in a document may
cause problems, novice XTM / Topic Maps users will not.

Novice XTM authors are not aware of the impact of the mergeMap
element. They will use it because it is in the syntax. They don't
imagine that the receiver of the XTM file may disable the processing
of mergeMap element because of security or other reasons. Or that the
user of the XTM file uses an application with a fixed or configurable
'mergeMap-processing-level'.
They assume that everything works fine, because the mergeMap element
is part of an international standard. They cannot know about the
provisos against the mergeMap element (either for security or other
reasons).

If the mergeMap element is not in the standard nobody can use it and
we won't have XTM reader implementations with different behaviours.

The self-contained XTM file will be proceed how the author of the XTM
document assumes that it will be proceed without taking care about the
security settings of the receiver.

Best regards,
Lars
-- 
http://semagia.com