[sc34wg3] Feedback on the TMCL requirements

[Lars Marius Garshol]

  TMCL REQUIREMENTS FEEDBACK
============================

Requirement #1: 
 - what does bullet point #2 mean?
 - bullet point #4 should be explained more clearly
 - in general, the text of this requirement could do with some
   expansion and polishing

Requirement #3:
 - I disagree with this requirement. To be useful, TMCL should cover
   the majority of user requirements. Obviously there will have to be
   a trade-off between completeness of features and ease of
   implementation (and comprehension), but making an 80% solution
   should not be the goal.

Requirement #4:
 - This is good, but it needs to be defined more clearly. It should
   also be spelled out in more detail.

Requirement #5:
 - Why not strengthen this by saying:

   "The syntax of TMCL shall be XML-based, and make use of the XTM 1.0
   syntax where applicable."

   instead?


Missing parts:

 - a proper "dependencies on other specifications" section would be
   appropriate

 - TMCL should support typing of occurrences; that is, it should be
   possible to say that all occurrences of type foo must be integers,
   numbers, booleans, dates, ...

   We should consider whether XML Schema, part 2 provides a good
   typing mechanism for our purposes.

 - TMCL should support constraining:
   - for classes of topics:
     - the number of base names in a particular scope
     - the number of variant names of each base name in a particular scope
     - the number of occurrences of a particular type in a particular scope
     - the number of roles of a particular type in a particular
       association that the topic may play
     - what other classes the topic may be an instance of

   - for classes of associations:
     - the number of players of each role type
     - permissible role types
     - permissible topic types of players of each role type

   - the form of URIs in variant names, occurrences, and subject identity

   (NOTE that constraining the numbers of something here means that 

 - there should be something stating to what extent and how TMCL will
   constrain implementations

 - should TMCL provide mechanisms for third-party extensions?

 - should TMCL provide features for self-documentation?

 - TMCL should clearly define what processors are to do in error situations

 - how should the TMCL XML syntax be defined? with a DTD? should it
   use namespaces?

 - TMCL schemas must not contain information that in any way modifies
   or enriches the topic maps that make use of them; schemas may
   modify the _interpretation_ of a topic map, but not the topic map
   itself


Low-bar proposal:

 - I consider it wholly inadequate, since it fails to support most of
   the TMCL requirements listed above (under "TMCL should support
   constraining:").

 - it should be taken out of the requirements document, and lead an
   existence of its own. Specific technology proposals do not belong
   in requirements documents.