The .LRN implementation must be easily extensible. The IMS LD specification may change in the future, so the .LRN implementation has to be done taking that into account. The .LRN implementation must be so flexible in order to adapt to the posible changes of the IMS LD specification. This means that if a change is produced in IMS LD specification, then this should imply only minor changes in our .LRN implementation of IMS LD. Also, if the initial specification should be extended it should be done in an easy way.
Reusability and standards
The implementation must follow, as much as possible, the standards defined by the IMS Global Learning Consortium. For example for the compatibility problem that was mentioned before, there should be an easy way to modify which .LRN service performs wich IMS LD service, and also to add a new type of IMS LD service and the corresponding .LRN service that will be in charge of dealing with it.
Our XML parser has to be aware of this flexibility, being easy to modify according to the, probably often, changes or improvements in the specification. The mapping between the service types and its corresponding .LRN services can be easily edited via web. Everything that can possibly change in the near future, must be easily extensible as this was mentioned in the previous section
The .LRN implementation must be easily extensible. The IMS-LD + specification may change in the future, so the .LRN implementation has to + be done taking that into account. The .LRN implementation must be so + flexible in order to adapt to the possible changes of the IMS-LD + specification. This means that if a change is produced in IMS-LD + specification, then this should imply only minor changes in our .LRN + implementation of IMS-LD. Also, if the initial specification should be + extended it should be done in an easy way.
Reusability and standards
The implementation must follow, as much as possible, the standards + defined by the IMS Global Learning Consortium. For example for the + compatibility problem that was mentioned before, there should be an easy + way to modify which .LRN service performs which IMS-LD service, and also + to add a new type of IMS-LD service and the corresponding .LRN service + that will be in charge of dealing with it.
Our XML parser has to be aware of this flexibility, being easy to + modify according to the, probably often, changes or improvements in the + specification. The mapping between the service types and its corresponding + .LRN services can be easily edited via web. Everything that can possibly + change in the near future, must be easily extensible as this was mentioned + in the previous section