[sc34wg3] Aug 3 meeting: Issue (term-tm-processor), Issue ( xtm-implicit-constraints):

[Mary Nishikawa]

>*Patrick
>Yes to defining a topic map processor, no to defining a topic map
>application. The difference is that a topic map processor takes a topic
>map (how that topic map came to be is deliberately undefined, we don't
>speak of topic map authoring) and performs operations on it. Note that
>the topic map processor is defined as processing "topic map information
>in conformance with this standard." In other words, the standard will
>define a set of operations on topic map information that if performed by
>a bit of software, qualifies it as a topic map processor. Note that the
>"how" of the operations, at least in an operational sense will not be
>defined. Just if you have condition 1 and condition 2 in a topic map,
>action (or non-action) #3 must result to qualify as a topic map
>processor. (Odd way to speak admittedly but does get a level of
>abstraction that allows for robust development.)

We will keep to this level of abstraction in the SAM, then.


>Only an application would be concerned with serialization (serialization
>is the convesion of topic map syntax (from however it is held) into a
>byte stream and deserialization is the reverse of that process).

Will a Top Map Application be defined elsewhere, or will this be 
implementation specific?

Sorry for asking all of these questions. I anticipate that I will be asked 
questions such as these at our local meeting, so I want to be prepared.


> > Issue (xtm-implicit-constraints):
> >
> > The XTM DTD contains a number of implicit constraints, such as that an
> > addressable subject may not be used as a theme or a type. Should these
> > constraints be mirrored in the SAM?
> >
> > SteveN: lets make SAM as clean as we can.
> > Lars, no other way around. XTM DTD looks as if certain things are
> > disallowed but they aren't.
> >
> > ***Decision: Not restricted, the implied constraints in the DTD.
> >
> > OK, I understand this to mean that even though these are implied and
> > are not actual contraints in the DTD we cannot assume that they are in
> > fact are. This will be taken care of by TMCL later on?
>
>No, I read this to mean that constraints that were implied by DTD syntax
>are not to be followed (because they really weren't meant as
>constraints) by the SAM. Restrictions will no doubt be authorized by the
>TMCL, but those will be on a principled basis and not implied by syntax.

This is clear. Thanks Patrick.

Best regards,
Mary