Specifications‎ > ‎

Future directions

LISS has been working well and stable for some time now, without much activity on the specification front.  

Some founders of LISS are happy with it 'as is', because it's working well and meeting their needs, and any non-backwards-compatible change would just be extra work for them.  However, there are some people suggesting changes or extensions:

* Compass has asked that the "daily timetable" data be reorganised into an upload of cyclical data plus an upload of explicit variations to this, so that e.g. they can display a 'cancelled class' object on timetables and to simplify their internal coding, and have more efficient timetable uploads.  They also want more details about teacher absences and covers, so that the information can go into the payroll system.  This has been specified in the "Proposed extension 1", not yet officially adopted into LISS.

* Vivo Miles (UK) would like to get attendance data out of SIS's using LISS.

* Tim Cooper doesn't like XmlRpc.  XmlRpc provides no benefit over plain XML other than that PHP has good support for it, and Tim's specific reasons for not liking it are:
     - It's poorly supported by .NET.  There is a .NET library for XmlRpc, and there are .NET implementations of LISS, but for whatever reason, .NET programmers generally seem to be less comfortable implementing XmlRpc.
     - it's such an inefficient encoding, e.g. 402K of xmlrpc compresses to just 22K.  

XML itself provides no benefit over JSON (other than dubious 'enterprisey' benefits).   In theory, there could be a JSON version of LISS without any additional specification work needing to be done.  Tim is not actually proposing this at this stage, just raising the issue in case there are other reasons to re-think the transport mechanism of LISS.

* eDiary were initially unclear on whether they should be client or server, and would like it if LISS worked completely symmetrically so that e.g. they could either call  'getStudents' or have a SIS call 'publishStudents' to them depending on which way they decide to go.  eDiary suggested that it would have been nice if LISS were implemented using REST.  An additional reason to use REST is so that incremental get/post requests for individual students etc. can be defined in a natural way.

* (Tim Cooper):  I should also add that I'm looking carefully at the improvements in SIF v3:  REST and JSON.  If SIF enhance their data model to include daily variation data then this *might* represent a convergence with the aims of LISS.