LLM CMS Specification Appendix B - Questions and Answers

This part of LLMCMSS summarizes questions being posed over time and their answers.

LLMCMSS.B.00 - Document Control

LLMCMSS.B.01 - Overview and Motivation

In principle, all questions should be answerable by the contents of the specification itself. Indeed, every question that is not covered by a part of the specification, results in updating the specification, if only to exclude certain aspects from the scope of the specification. However, some answers are not so easy to find by only reading the specification text. Moreover, some questions will be asked moe often as they come to mind frequently. So, in order to provide one more aspect to the matter, this part answers the questions and provides sort of a commentary to help in understanding some of the not so obvious parts of the formal specification text.

LLMCMSS.B.02 - Questions and answers in Detail

1. Q: I went through the “LLM CMS Use Cases” and as I see the GUI plan of RUI part is not complete yet. Can I rely on a final version soon or is it just meant to be a guideline to see how it should look like? In the latter case I would figure out the required RUI functionality through the WSDL and documentation.
   A: As of LLMCMSS V 0.8, there are only few,  but most versatile functionalities in the RUI.
   A: The RUI functionality is explicitely specified in LLMCMSS.04.05
   1. Senior training result viewer
   2. Property editor.
      The property editor can be usede to manage senior data, equipment data, schedules and appointments and even training programmes
   3. General Object Editor
   4. Schedule Editor
   5. User Manager (add/remove/modify)
       
2. Q: I checked the Web Service API documentation and I would like to suggest a few enhancements if you don’t mind.        ->  Evdokimos ?  (WH)
   Seniors are identified by ID and the delete, get, edit works by using this ID only. Thus if the admin e.g. wants to edit a user’s profile the system has to get all seniors to get the ID. I would suggest e.g. find_seniors(“fname”, “lname”, “country”,“city”,”active”, “username”, “password”)  method with optional parameters so the query can be targeted to specific users. Or is it expected from the admin/therapist to remember IDs?
   In case of Users there can be  find_users(“fname”, “lname”, “Role”, “username”, “password”) method as well for the same reasons described in the previous section.
   It would be helpful to have an API method (e.g. get_seniors_of_user(“user_id”, “username”, “password”)) which returns all the seniors associated with a user. Or the  get_seniors_relations_from_user method could do that if the senior_id parameter is zero and the user has permission to get his/her associated seniors.
   Is it possible to extend the Web Service API with above mentioned functionalities?
   A(WS): will forward this to AUTH/EK along with the suggestion to include the tree-API also into the LLM-WS
   I completely agree with your proposal for a "xxx_find" functionality in the LLM-WS, I would like to ask the guys from AUTH to provide the tree-API I suggested in LLMCMSS.04.02.14 already on the LLM-WS. By using this API and a "list" or enumeration functionality, all objects in a certain context could then easily be found.
   Additionally, I enhanced LLMCMSS.09 be the requirement, that every database object shall have its unique, immutable ID.
3. I saw in the “LLM Reference Architecture 0.7” figure the “RUI blue box” in the CTC and PCT and the Web-RUI in the ILC box which I don’t fully understand. As I understood the RUI is a web-based interface for remote access via the Internet (for care takers, trainers, admin) and not for directly managing e.g. a PTC equipment.
   A:  the RUI in the PTC box is completely conceptual, has nothing to do with CMS RUI and is assumed to have no integration into CMS. It's out of scope. All PTC management interaction is intended to be by LLM-DB properties entries.
4. Q: Shall we take care of the logging functionality to log all the actions done through RUI? Or is it done at Web Service side?
   A:  LLMCMSS.04 specifies that all CMS-Web-Service activity shall be logged. If the RUI accesses functionality that the web-service also provides, this shall also be logged, although the CMS RUI web-application will most probably not go through the SOAM-mechanism to manage things like users or schedules. I'm not sure if it makes sense to log anything (except for the usual debug and troubleshooting logs) inside the RUI.
   However, things like session setups, logins, LLM-DB changes etc. shall be logged (as they are offered on the CMS-WS).
5. Q: Is there test data in the LLM-DB to test the LLM Web Service API? If so can we have access to it?    ->  Evdokimos ?  (WH)
   A: WS already asked AUTH/Evdokimos to provide a LLM-DB test-installation with the already existing web service and including test data. PLease dont expect too much here, as these data is either completely synthetical and therefor not very realistical or very confidential and therefore incomplete at best!
   WS to ask Josef to further keep track of that matter.
6. Q: As I see the passwords are not encrypted at the moment. Will this change in the future or how will the security take place?
   A: expect passwords not to be stored in cleartext, especially passwords of user accounts providing broader access. I suggest to hash passwords, like in the Unix-OS and to store only the hash value. Entered passwords when authenticating will then also be hashed and can thenm be compared.
   
7. Q: this training result viewer. what kind of features does it have?
   A: The training result view on the RUI is specified in LLMCMSS.06.02.04, but not specifically for the RUI. In essence it shall be able to view training result reports produced by the LRF. The LRF shall produce training results for each target audience: seniors (to be displayed at LUI), therapists and relatives (displayed at RUI). All these reports are HTML documents and are marked with the senior, the training programme, the session (if applicable) and the target audience.
   There are already raw training results in the LLM-DB in the "CTC/PTC seniors activity" objects. I'd expect the reports to stored in the generic "properties" or in the user-specific "properties" sub tree. The report itself, being an HTML document can in the essence be stored in a single STRING-type property. The pictures to be included and CSS-stylesheets and other formatting elements shall be managed in a filesystem tree on the platform the LRF and the RUI are running, more detailed specified in LLMCMSS.08.02.16 and LLMCMSS.08.02.15.
   A: RUI based training result viewer is explicitely specified in LLMCMSS.04.05.05
   
8. Q: can a trainer get notification?
   A: A trainer is not forseen to receive any notification, only (video) calls for supporting seniors, but this is not part of LLM system functionality. LLM system need not foresee such a thing, except it can be covered by a LUI functionality/workflow.
9. Q: can notification appear in RUI?
   A: For the time being there is no notification to appear in RUI. RUI, for the time being, has no callback-mechanism foreseen. However, there is hope that wicket or another component based framework would support such a functionality.
10. Q:  everybody can send notification to anybody?
    A: Notifications are intended to be used by the system, not by users. There are currently 2 sources of notifications:
        1) the ILC danger or stress detection, producing a notification with the "distress confirmation screen"
        2) The appointment management system, producing a notification when an appointment is due.
    Each notification may evoke its own user dialogue: an distress alert notification would evoke the "distress confirmation screen", a training schedule would evoke a dialogue with a button to immediately start the training.
11. Q: ad LLMCMSS.04: Lock/Unlock User Account is ok, but what do you mean by Lock/Unlock Session
    A: Lock/Unlock session would mean that the user leaves the terminal and the terminal and session stays locked unless the user again provides password or other credentials. No specific user procedure and use case for now.
12. Q: what did you mean by "change terminal" here at LLMCMSS.04.02.5
    A: I thought, that there may be a scenario where a user would move from one terminal to the other but keep her/his session with all status and credentials. From the session point of view it would only mean changing the reference to the active associated terminal. No defined user procedure and use case do exist now.
13. Q: Sessions as in LLMCMSS.04.02.5; do we have to keep track of users?
    A: A session should be existing as long a user is logged in. It shall be used to store session-wide values, e.g. the position where the property editor has its current editing point, the current user, the local terminal the user has logged in, etc, ...
14. Editing various things: the general object editor, a discussion:
    Q:  About editing various things: trainer has to have a place at RUI where he can create trainings, appointments, schedlure.
    A: This is correct, there are already some sketches for a LUI-based schedule editor. Woiuld need to complete them for RUI purposes.
        On the other hand, there is a thought that comes to mind:
        Could there be a generic object editor?
        There is already the general property editor, but this one is not aware of the specific semantics properties ob objects have, not even time- and date-values.
        A general object editor will need some meta-information about classes of objects: what properties of what type and how to enter them in what kind of user interface and how to check them to be consistent.
        If we could think up such ageneral object editor, we had a great component for all types of information managed in the LLM-DB. The metadata about classes and their properties could be stored in the LLM-DB Tree itself.
    Q: could you please write an example of a generic object and a general property?
    A: An object would be an appointment. The appointment class would have a few properties: a date/time, a task, a user for whom the apointment is and some repetition properties
        A genral editor editing an appointment would neeed to know that an appointment had these properties and what value ranges these properteis would have to have. It could take this meta-information for the meta-information property tree.
    Q:  is the metadata for "connecting" properties to objects?
    A: The editor could then e.g. offer a date/time chooser for the date/time values, offer a dropdown-list for a limited-value range or complain if somebody entered the 31-FEB.
        Sorry about terminology confusion:
        An object would be anything having a name and any number of properties.
        In the LLM-DB-tree-API objects would be in the nodes of the tree, having properties being primitive values or objects with arbitrary properties themselves.
        Adding an object would be accomplished by adding a subtree to the total tree, thus adding an object with a speficic name and unique ID into a specific place in the tree hirarchy.
        An example using the appointment again:
        A "senior"-object has a number of fixed properties, like defined in the LLM-WS and, additionally, a set of generic properties by having a "properties" tree attached to it. In the "properties" tree, an "appointments"-subtree can be created. Each item in this "appointments" tree being one appointment with a number of properties, as defined for an appointment.
        The only fixed meaning given to positions in the tree and enforcing specific names of properties is in the software processing the appointments, in this case the CMS managing the appointments and notifying users if an appointment is due.
        The difference between the generic property editor and a general editor using metadata to enforce the intended meaning of properties is like having a file-system:
        you could edit each file with a hex-editor, but you have to know what you're doing, and it's dangerous, not to mention boring.
        Therefore there are different tools: text editors, word processors, outlook, excel, ...
    Q: how can we imagine the metadata in the tree?
    A: I can imagine a subtree called "CLASSES", each entry being a class definition carrying the name of the class. Ech class definition would have a "MEMBERS" subtree, each entry being the definition of a member variable carrying its name and having properties defining its type and value ranges etc, ...
    Q: as I see, objects, are members, users, Components.. and unlimited properties can connect to these objects.
    A: Thats right. The metadata can then also contain information about how to present such an object on the RUI, how to enter the value and many more.
    A: The General Object Editor, abbreviated GOE, is explicitely specified in LLMCMSS.04.05.03
15. Q: How may a generic node in the LLM-DB tree look like and what attributes shall it have?
    A:
    1. It shall be able to hold:
       1. a NUMBER value
       2. a STRING value
       3. a NAME
       4. a PARENT reference
       5. an ACL reference
       6. a bit-mapped FLAGS mask
    2. The reference fields shall be numerical references uniquely referrring to another tree node.
    3. The NUMBER value shall have the same numerical range as the reference fields in order to be able to re-use the NUMBER also as a reference.
16. Q: How can a implementation model for access control security on the LLM-DB tree look like and what features shall it have in detail?
    A(1): The security shall consist of an access control scheme allowing to grant separate rights for READ, CHANGE, ADD, DELETE on each single node in the tree. The API to access the tree shall check the relevant access permissions before performing the respective operation (Read, Enumerate, Change, Add, Delete). The tree API shall be enhanced by security checking utility methods like "check_read_access(node_id)". If an API call enumerate nodes in a sub-tree, nodes not allowing READ for the security principal invoking the function shall not be enumerated. For a client principal having no READ access right for a certain node, this node shall not be visible, as if it were not even existing. There may be special cases to be considered in this case if a enumeration method is used to check the uniqueness of a name or picture code. Most probably, adding nodes with to-be-unique properties or changing to-be-unique values will have to be executed with higher privileges capable of always READing the complete data set involved. Another concept would be to integrate such operations in the tree API and to allow complete enumeration of the subtree in case of ADD or CHANGE permitted for one sub-node in the tree, but this complete enumeration would only be carried out in the tree API and would not comprise a security leak.
    A(2): The rights shall be assigned to entities identified by so called rights identifiers. Rights identifiers shall be entities able to be owned by users, groups or roles. Assignment of rights shall be stored in access control entries (ACE). One access control entry (ACE) shall assign any combination of READ,CHANGE, ADD, DELETE to one rights identifier. To each node in the LLM-DB tree there can be an access control list (ACL), consisting of access control entries (ACE). If a specific tree node does not have an ACL attached to it, access control may be specified by any of its ancestors in the tree (parent, parent of parent, etc.)
17. Q: How can we implement access control to API methods, menu items, GUI operations and other objects not explicitely in the LLM-DB tree?
    A(1): Access control must, as with the LLM-DB tree, be checked by the relevant methods, functions or procedures executing the function behind the API or GUI control.
    A(2): In order to store access control information to non-tree objects, there shall be proxy-objects in the tree carrying the ACLs for the external entities.
18. Q: Where shall the ACL for any tree node be stored.
    A: One implementation my be to equip each node with an ACL-reference. The ACL would then by built up also by nodes in the tree, only assigned a special meaning to represent an ACE. The parent-reference may be used as a linking reference between all ACEs of an ACL.
19. Q: How shall a tree-node be used as an ACE?
    A: The FLAGS mask shall be used to store flags for READ, ADD, CHANGE and DELETE rights granted. The NUMBER field shall hold the rights identifier
20. Q: How will the unified tree for a sample set of users look like
    A: An example of the unified tree as seen "thru the eyes of" LLMCMSS.04.02.14, including the possible mixture of already existing fixed structures and flexible add-ons by properties may look like the following:
    "/" - type PROPS (root)
    "/USERS" - type PROPS (the fixed part already provided by the LLM-WS "users" structure, mapped to the virtual tree as seen by unified tree API
    "/USERS/klaus_schwarz" - type PROPS
    "/USERS/klaus_schwarz/lname" - type STRING (the fixed "lname" field of the "user" structure)
    "/USERS/klaus_schwarz/fname" - type STRING (the fixed "fname" field of the "user" structure)
    "/USERS/klaus_schwarz/properties/user_birthday" - type STRING (the optional property named "user_birthday" added to the properties attached to the user)
    "/USERS/klaus_schwarz/properties/children" - type PROPS
    "/USERS/klaus_schwarz/properties/children/Frank" - type PROPS
    "/USERS/klaus_schwarz/properties/children/Frank/age" - type NUMBER
    "/USERS/klaus_schwarz/properties/children/Thomas" - type PROPS
    "/USERS/klaus_schwarz/properties/children/Thomas/age" - type NUMBER
    "/CTCS" - type PROPS (the fixed structure collecting all LLM-WS objects of class "CTC")
    "/CTCS/COMPONENTS" - type PROPS (collection of all CTC components)
    "/CTCS/COMPONENTS/treadmill_11/" - type PROPS
    "/CTCS/COMPONENTS/Wii_23" - type PROPS
    "/CTCS/ACTIVITIES" - type PROPS (collection of all activities of class CTCactivity)
    "/PROPERTIES" - type PROPS (the system-wide free space for managing arbitrary configuration and other properties)
    "/PROPERTIES/sysconfig/DistressResponseTimeout" - type NUMBER (the system-wide lenght of the reponse timeout in seconds)
    "/PROPERTIES/CLASSES" - type PROPS (the subtree containing all higher level class definitions)
    "/PROPERTIES/CLASSES/USER" - type PROPS (defining the higher level class USER)
    "/PROPERTIES/CLASSES/USER/fields/Age" - type PROPS (defining class field "Age")
    "/PROPERTIES/CLASSES/USER/fields/Age/range_min" - type NUMBER (defining minimum allowed value for Age)
    "/PROPERTIES/CLASSES/USER/fields/Age/range_max" - type NUMBER (defining maximum allowed value for Age)
    "/PROPERTIES/CLASSES/USER/fields/Reference_ID/type" - type STRING (defining the type of the field "Reference_ID", may be STRING or NUMBER)
    "/PROPERTIES/CLASSES/SENIOR" - type PROPS (defining the class SENIOR)
    ... etc ...