[sc34wg3] [SAM] scope-weak-definition
Tue, 27 Aug 2002 10:59:42 -0400
It was noted in the proposed SAM minutes from Montreal that "scope" was
considered to be "weak."
In the context of the SAM (as opposed to RM, syntax, etc), can someone
elaborate on what is "weak" about "scope" in the SAM?
The main reason I ask is that I thought we were much more productive on
small (and large) issues at the last meeting with Lars' summary of the
issues for any given question. That is a practice I think would be
useful for list discussions. (This will only work if we restrain
ourselves by clearly identifying the model or level we are discussing.
Does not limit the discussion, just means what is under discussion
should be clearly identified.)
If we can get an idea of what is "weak" about "scope" it should help
focus dicussion on those issues as well as any proposed cures for such
Hope everyone is at the start of a great week!
Director of Research and Development
Society of Biblical Literature
Lars Marius Garshol wrote:
> * Mary Nishikawa
> | Issue (term-tm-processor):
> | Do the definitions of the terms 'topic map processor' and 'topic map
> | applications' have unwanted consequences for what software
> | architectures can be conforming implementations of this standard?
> | ------------------
> | We all agreed that the answer to this was "yes."
> We agreed that the answer was that they might, but that we could work
> around that by wording the conformance clause in the right way.
> | We agreed to define the term "topic map processor", but not define
> | "topic map application." Is this correct?
> Not really. We will define both, but not constrain what instances of
> the second are allowed to do.
> | If we do not define "topic map application," then we do not need to
> | discuss this serialization and deserialization business.
> We don't anyway. It's not really related to this question. :)
> | I want to confirm that we agreed not to define "topic map
> | application" in the SAM. Is this correct? If it is then, don't we
> | still need to possibly define what an XTM application is, in general
> | terms at least in the SAM?
> We would, but we now do away with that by defining "topic map
> application" as something independent of whether the application
> happens to use XTM syntax, HyTM syntax, or perhaps no syntax at all
> | I think that there is some ambiguity in how "application" and
> | "processor" are used in the XTM spec.
> | We have three terms, "XTM processor" and "XTM processor application"
> | and "XTM application" in the XTM spec. We have terms such as
> | "application-specific processing" all over the place.
> Actually, the XTM 1.0 glossary defines none of these terms. I see that
> it does use all of these terms and I would guess that they are all
> meant to be equivalent, but since there was no officially defined term
> the editors ended up using three different terms for the same thing.
> All of this will be replaced by "topic map application", however, so
> this is one problem that the new ISO 13250 will fix.