[topicmaps-comment] Ontopia Schema Language (Specification), Feedback

[Robert Barta <rho@bigpond.net.au>]

Hi Lars,

Here are my comments/suggestions/questions regarding the OSL spec:

Specification

  - abstract:  .....exhaustive....

    Well. :-)

  - can be adopted as TMCL as-is, __and__ is

    Suggest: "and"

  - Q: Does OSL allow to have 'loose' and 'strict' on a topic-by-topic
    basis? This is a feature which certainly does not apply to a 
    _complete_ map.

  - ....controls whether the __schema__ uses loose...

    Suggest: 'validation' instead

  - The stress on a ruleset having only one ID attribute is redundant if
    you define ID as and XML id.

  - Q: can you reference a ruleset from an association also? Only topic
    classes are mentioned.

  - I'm not too happy of the term 'class' for something which is actually
    a rule doing the constraint. The term 'class' is too heavily overloaded
    in the TM area.

  - Is a class (=rule) only triggered/activated if the instanceOf value
    matches? Cannot I match by, say, part of a baseName or an occurrence?

  - ....contain constraints on the characteristic __of__ instances of the class

    Suggest: 'of'

  - If set to loose __,__ ...

    Suggest: add ','

  - According to the DTD the element is called  otherClass and not otherClasses.

  - ...what other class__es__ instances

    Suggest: no plural here

  - I see now 4 different mechanism to deal with the minimum/maximal issue at
    constraints:

      otherClass element: used for the transitive closure of types
      minimum/maximum attributes
      strict/loose
      superset/subset

    Would it be possible to merge them all into one mechanism in the language?
    Or, at least reduce them?

  - 2.4 ....If a base name __in the map__ has __a__ scope

    Suggest: add _in the map_ not to confuse that in the constraint
    Suggest: add _a_

  - general: Maybe double-check whether it is always clear what is the condition
    of a rule/constraint to be activated and what is that the map then has to
    match.

  - 2.4 ...Matching of variant names is always strict.....
    2.5 ....The variant element...

    Is this not some contradiction? Probably I do not understand it correctly.

  - 2.5 ...If a variant has __a__ scope

    Suggest: add __a__

  - 2.6 ...If the occurrence element has a scope child element __,__

    Suggest: add __,__

  - 2.7 Typo: Defins

  - 2.7 ...As long as the containing association matches __any__ of those ...

    Suggest: __any__ instead of __one__ is intended?

  - 2.9 Maybe use <roleSpecType> instead of <instanceOf>? I always try to avoid
    confusion about 'types' and 'roles' in associations. This is a usual pitfall
    for authors to use types as roles like in

    (kills)
    person : james-bond
    person : dr-mabuse

    and not

    (kills)
    killer : james-bond
    victim : dr-mabuse

  - 2.9 Q: Is it possible to constrain players as well? Say, as in

    (kill)
    killer : $a
    victim : dr-mabuse

    AND

    $a (secret-service-agent)

  - 2.9 (inside the table): ....constraint for each __class__

    Is 'class' really meant here?

  - 3.2 If the element is empty it means that the object __must have no
    type__ in order to match.

    MUST HAVE NO or NEED not have to? Is this a precondition or the constraint itself?
    How can something have no type? Hmmm.

  - I did not check the DTD.

\rho