With the successful roll-out of the Experience API (xAPI) the foundation for a new SCORM standard has been laid. By itself, xAPI is not a replacement for SCORM. Instead, xAPI defines communication between a learning experience and the learning record store, or LRS. While most of us agree that the majority of learning occurs outside the LMS, there is still some formal eLearning that will be maintained in the LMS, so a more modern SCORM is certainly needed. Now that ADL is taking over the cmi5 specification from the AICC, it is clear that cmi5 is the “next generation” of SCORM. This article provides an introduction to this powerful new specification.
This is part 2 of a 2 part article. In part1, we discussed the history behind xAPI, why xAPI was developed and some of the benefits assocaited with xAPI. In part 2 of this article we will learn how xAPI works, define the Learning Record Store (LRS) and dispel some of the myths about xAPI.
The Experience API (xAPI), often called “Tin Can”, was released on April 26th, 2013. There are already over 70 adopters of xAPI and the level of industry “buzz” has been unprecedented. So what is it? Is it something you should know about? In this session we will introduce you to xAPI and show how it is impacting the learning industry. We’ll also show you the benefits of xAPI and how it can help record a wide range of learning experiences for your students. This is part 1 of a 2 part article.
Why “File://” Links Are Bad
Many VTA users setup document links in Learner that use the “File://” syntax instead of using a web folder. This type of link is called a “local security zone” link by Microsoft. While this is an easy shortcut, it has many problems that we will discuss in this article, including:
•It is a security nightmare.
•Users may not have access to the folder location.
•Microsoft does not support it.
Think about it; you are getting a network file location from a remote server and asking your desktop to open that file. In the case of VTA, this may not seem so bad; the File link is setup by a VTA Administrator, so it should be safe to open the file. But what if some unknown web site tried to open a file on your computer (or your network)? Clearly, that would not be something you should allow.
We frequently get help desk calls about students not being able to open a file from a network location. The problem is often security related. Local users at a site may have access to the location, but remote users may not. If the files were instead posted in a “virtual folder” on a web server, granting access would be much simpler.
Microsoft Does Not Support It
While it may work to use a “file://” link, Microsoft has never supported it when the link comes from a web server that is not in your “domain”. This means that it might work great for a server inside your firewall, but may or may not work from a server outside your firewall. Lately, Microsoft has been cracking down on this type of link and recent patches to Windows have rendered “file://” links invalid. Even when it worked, it was considered an “undocumented feature” of Internet Explorer.
“But it works when I type it in the Address Line”
If you type a “file://” link directly into the address bar of Internet Explorer, it still works. Why? Well, Microsoft allows this type of link when you type it in; it’s no different than browsing to the file from Windows Explorer. But if the link comes to you from a remote server via a web page (VTA, for example) rather than being typed in by hand, Microsoft will now prevent the file from opening. Microsoft calls this “Local Machine Zone Lockdown”.
The only workaround to this issue involves editing the registry on the desktop to disable the Local Machine Zone Lockdown. You will need to discuss this with your IT group, and most likely they will not allow it as it is a glaring security hole.
Documents and files that you wish to launch from Learner should reside on a web server. Ask your IT group to provide a virtual folder on a web server where you can post training related files. Then you can use a valid URL to launch the files rather than a “file://” link.