I was interested in what the thinkig was behind the "future" proposals to add XML/XSLT to Moodle 2.
I'm asking this having done quite a bit of *static* development using XSLT and I can't see any benefit of such an arrangement in a live environment: (a) because it will probably be slow, (b) can you rely on a PHP installation having XML support compiled in and (c) why bother anyway.
I would be happier to see an incremental evolution, probably by firstly concentrating on a move to "proper" CSS based presentation (ie, take out all the font tags etc). One has to consider though that there are still lots of people in education using Netscap 4!
We've been having a look at Smarty here (smarty.php.net) and it looks really exciting - I think this has been mooted before. May beworth another look.
As regards XML it may be worthwhile adding modules within the current structure to handle IMS and/or SCORM input and output, but even that would, I think, require enough people to demand it to make it worth all the bother - I have done some work with IMS recently and its *really* nasty! ...and that was in Java which handles XML a lot more easily than PHP does.
The XML being talked about involved heavy caching, but don't worry Smarty is definitely on the agenda still (see this post). I've used Smarty in other projects and it's great.
XHTML compliance is a must, regardless of the way is will be generated - no question about that.
XHTML compliance is a must, regardless of the way is will be generated - no question about that.
I read the linked post and it reminded me of a question I had for you:
It appears to me that smarty templating was being mooted as a rival technology to XSLT and a choice had to be made between the two.
If this is the case then my question is what would be used to generate the XML that is then transformed via XSLT into the final (X)HTML output?
The best answer seems to be smarty!
Is this what you mean when you say it is still on the agenda?
It appears to me that smarty templating was being mooted as a rival technology to XSLT and a choice had to be made between the two.
If this is the case then my question is what would be used to generate the XML that is then transformed via XSLT into the final (X)HTML output?
The best answer seems to be smarty!
Is this what you mean when you say it is still on the agenda?
Note the age of some of the posts. I really like the idea of XML/XSLT - theoretically it's very clean and solves a lot of problems. And it's widely accepted as a standard.
However, this templating standard simply isn't PRACTICAL yet. Support is minimal, it's complicated to set up with PHP, there are performance issues, etc. Since I have no time to start on Moodle 2 at this stage, my current thinking is to keep an eye on XSLT-related technology. IF it hasn't matured enough by the end of the year, THEN I'll most likely use Smarty instead (for speed, simplicity, robustness etc). I'm not aware of any way that Smarty and XLST can be used together (they are competitors really).
While doing this major conversion (either way), all the current old HTML will be cleaned up into XHTML with more complete CSS control. XHTML isn't really innovative but it is more standard than the "quirks mode" HTML most sites use now. This CAN still be done in a way that retains backward compatibility with old browsers (eg using TABLE instead of DIV), but I think by the end of this year it's going to be hard to argue for the need to be fully compatible with Netscape 4 and IE 4.
Does that make sense?
However, this templating standard simply isn't PRACTICAL yet. Support is minimal, it's complicated to set up with PHP, there are performance issues, etc. Since I have no time to start on Moodle 2 at this stage, my current thinking is to keep an eye on XSLT-related technology. IF it hasn't matured enough by the end of the year, THEN I'll most likely use Smarty instead (for speed, simplicity, robustness etc). I'm not aware of any way that Smarty and XLST can be used together (they are competitors really).
While doing this major conversion (either way), all the current old HTML will be cleaned up into XHTML with more complete CSS control. XHTML isn't really innovative but it is more standard than the "quirks mode" HTML most sites use now. This CAN still be done in a way that retains backward compatibility with old browsers (eg using TABLE instead of DIV), but I think by the end of this year it's going to be hard to argue for the need to be fully compatible with Netscape 4 and IE 4.
Does that make sense?
I wish the problem could be as simple as drawing the line at NS4 & IE4 
The more recent browsers also suffer from serious drawbacks in many cases, like not being able to interpret the old and well established CSS1 standard correctly.
But I agree with your reasoning.
The more recent browsers also suffer from serious drawbacks in many cases, like not being able to interpret the old and well established CSS1 standard correctly.
But I agree with your reasoning.
I'm interested in XML/XSLT. I am working on the descriptions for some courses and would like to write the description in XHTML and then translate with XSLT to something that can be loaded into the Moodle database. If someone was interested in this and wanted to do the database part, I can get the XHTML/XSLT part going.
Let me know if anyone is interested.
Moodle 2 stuff perhaps but could be useful for 1.0.9+
Gary
Let me know if anyone is interested.
Moodle 2 stuff perhaps but could be useful for 1.0.9+
Gary
Are you sure?
...and don't get me wrong, I'm a fan of XSLT, but, having given this some thought I am unsure how to apply it to Moodle. The problem we found here is that non technical users cannot (or will not) edit XML files (or HTML files). This leaves the editing and maintenance of course materials in the province of the Moodle administrators or other IT literate people.
I'm not convinced that this is the way forward (..and ask me how I found this out!). I myself am very interested in finding a way of putting useful formatting facilities into the hands of the educationalists who actually develop the course - who, certainly in our case, would not get on with XML/HTML technologies.
I am currently modifying (fighting with) Moodle to add a resource type called "TikiText", which we 'stole' from the Blog world. This is a very simple formatting system (example: *this will be bold*, /this will be italic/), that users find more intuitive. You are quite right though - this kind of thing really needs to be built in to Moodle to be truly useful.
I also wonder what complexity of formatting you actually need that goes beyond what can be done with the existing Moodle facilities, given that you are willing to get your hands dirty with any kind of mark-up in the first place.
Having said all that --- as I am doing something similar at the moment, if I crack this and there is some interest I would be happy to have a look at putting this together. (I would then be starting to worry that there are too many fundamentaly similar resource types!).
...and don't get me wrong, I'm a fan of XSLT, but, having given this some thought I am unsure how to apply it to Moodle. The problem we found here is that non technical users cannot (or will not) edit XML files (or HTML files). This leaves the editing and maintenance of course materials in the province of the Moodle administrators or other IT literate people.
I'm not convinced that this is the way forward (..and ask me how I found this out!). I myself am very interested in finding a way of putting useful formatting facilities into the hands of the educationalists who actually develop the course - who, certainly in our case, would not get on with XML/HTML technologies.
I am currently modifying (fighting with) Moodle to add a resource type called "TikiText", which we 'stole' from the Blog world. This is a very simple formatting system (example: *this will be bold*, /this will be italic/), that users find more intuitive. You are quite right though - this kind of thing really needs to be built in to Moodle to be truly useful.
I also wonder what complexity of formatting you actually need that goes beyond what can be done with the existing Moodle facilities, given that you are willing to get your hands dirty with any kind of mark-up in the first place.
Having said all that --- as I am doing something similar at the moment, if I crack this and there is some interest I would be happy to have a look at putting this together. (I would then be starting to worry that there are too many fundamentaly similar resource types!).
>Are you sure?
Yes
>...and don't get me wrong
np - I posted thinking you would have some input
What I am interested in having is:
Course descriptions in HTML.
Read the HTML and put into Moodle db.
The descriptions have:
course name
instructors
description
and can 'know' that guest users can view or that the course requires a key...
We can read the HTML and get the info and then use the info to update the Moodle db.
That lets us have HTML that is in sync with Moodle. We could use templates with forms to generate the HTML to get the HTML class attributes etc. We could use the tool tidy to convert the HTML to XHTML so we can parse it. We would write the XSLT so there is no issue of users being 'forced' to write XSLT.
>I'm not convinced that this is the way forward
How did you find that out?
>I am currently modifying (fighting with) Moodle to add a resource type called "TikiText"
...
>You are quite right though - this kind of thing really needs to be built in to Moodle to be truly useful.
I'm more going the other way. Pass info into Moodle from other sources.
Can you say more how adding a resource type "TikiText" is easier than editing with a WYSIWYG HTML editor (that knows about our attributes)?
Good input. Thanks
Gary
Yes
>...and don't get me wrong
np - I posted thinking you would have some input
What I am interested in having is:
Course descriptions in HTML.
Read the HTML and put into Moodle db.
The descriptions have:
course name
instructors
description
and can 'know' that guest users can view or that the course requires a key...
We can read the HTML and get the info and then use the info to update the Moodle db.
That lets us have HTML that is in sync with Moodle. We could use templates with forms to generate the HTML to get the HTML class attributes etc. We could use the tool tidy to convert the HTML to XHTML so we can parse it. We would write the XSLT so there is no issue of users being 'forced' to write XSLT.
>I'm not convinced that this is the way forward
How did you find that out?
>I am currently modifying (fighting with) Moodle to add a resource type called "TikiText"
...
>You are quite right though - this kind of thing really needs to be built in to Moodle to be truly useful.
I'm more going the other way. Pass info into Moodle from other sources.
Can you say more how adding a resource type "TikiText" is easier than editing with a WYSIWYG HTML editor (that knows about our attributes)?
Good input. Thanks
Gary
Gary, if you're going to be writing forms to collect data and generate the HTML to convert to XHTML to parse and input into the Moodle database.. why not just write a script that inputs the form data directly into Moodle's database?
Actually I'm a bit puzzled why you don't just paste the original HTML straight into the course settings page ..
Actually I'm a bit puzzled why you don't just paste the original HTML straight into the course settings page ..
> Gary, if you're going to be writing forms to collect data and generate the HTML to convert to XHTML to parse and input into the Moodle database.. why not just write a script that inputs the form data directly into Moodle's database?
Martin, that is pretty much what I could do. The script will be in XSLT.
I can extract the data from the page and translate it with XSLT to a sql file that can be used to add/replace the data in whatever db Moodle is using.
The stuff about using forms etc. was me throwing a bit in about ways to make sure the HTML is the way I want it to 'look'. I would only have one form, a course description form.
Converting from HTML to XHTML is easy. Use tidy http://tidy.sourceforge.net/.
>Actually I'm a bit puzzled why you don't just paste the original HTML straight into the course settings page ..
What I currently do is to enter the course data into Moodle then view the info in my browser and then save the page. Then start editing and paste what I have back into Moodle.
I can ask others to start Moodle, log in and then cut and paste. Or I can have a simple XSLT stylesheet that will do the trick. The HTML is the 'source' not Moodle. I want to have the data that Moodle use get it from the source.
And I was posting to let people know that if they want to look a bit at XHTML/XSLT that I could help them start. I thought that was a direction you wanted to look into. Moodle 2.0ish stuff.
Martin, that is pretty much what I could do. The script will be in XSLT.
I can extract the data from the page and translate it with XSLT to a sql file that can be used to add/replace the data in whatever db Moodle is using.
The stuff about using forms etc. was me throwing a bit in about ways to make sure the HTML is the way I want it to 'look'. I would only have one form, a course description form.
Converting from HTML to XHTML is easy. Use tidy http://tidy.sourceforge.net/.
>Actually I'm a bit puzzled why you don't just paste the original HTML straight into the course settings page ..
What I currently do is to enter the course data into Moodle then view the info in my browser and then save the page. Then start editing and paste what I have back into Moodle.
I can ask others to start Moodle, log in and then cut and paste. Or I can have a simple XSLT stylesheet that will do the trick. The HTML is the 'source' not Moodle. I want to have the data that Moodle use get it from the source.
And I was posting to let people know that if they want to look a bit at XHTML/XSLT that I could help them start. I thought that was a direction you wanted to look into. Moodle 2.0ish stuff.
Ahh... I think I may have missed the point slightly.. but I still don't get it!
Is this a roundabout way of implementing something like the CTI XML specifications?
I still don't really see where the XSLT fits into this. XSLT is primarily used to transform XML into another lot of XML, quite often XHTML - but I don't see the step from here to SQL. SQL is fundamentally not like XML (it would be grim indeed to write XSLT to generate SQL), and what you want to do sounds to me like you are trying to push the technology to do something it won't like.
To take a step back, what problem do you have that you are trying to solve?
Is this a roundabout way of implementing something like the CTI XML specifications?
I still don't really see where the XSLT fits into this. XSLT is primarily used to transform XML into another lot of XML, quite often XHTML - but I don't see the step from here to SQL. SQL is fundamentally not like XML (it would be grim indeed to write XSLT to generate SQL), and what you want to do sounds to me like you are trying to push the technology to do something it won't like.
To take a step back, what problem do you have that you are trying to solve?
I'll joke a bit and see if that helps open up some new thoughts. Consider, if your only tool is an axe, every problem looks like a tree.
I have classes in HTML. I have lots of tools, and thought it would be fun to use XSLT to extract the info needed to add the classes into Moodle with XSLT.
I had never heard of CTI XML, is it a RAD tool for extracting from PowerBuilder? Regardless,
the problem I am trying to solve is getting my HTML classes into Moodle. I currently do it by good ol cut and paste. I can automate that and thought it would be fun to use XSLT. That would also give some hands on experience with what XML applications could be described for working with Moodle.
In my opinion XSLT is a tool to transform XML and can be used to generate other XML OR text. An example is generating sql statements that can be used to update a sql database. I have done that with industry standard calendar data, taking the data in XML and generating SQL that can update a database of calendar info. It is VERY EASY to do.
If you have XSLT that can translate XML to SQL, it is easy to get it to produce HTML. The XSLT used to generate the SQL could also generate HTML in various ways that goes beyond CSS.
I find XML/XSLT similar to SQL. If the XML has rows and columns, it looks a lot like a SQL table. XSLT can do many of the same things to that XML that you can do with SQL.
But that is another conversation and I don't want to be barking up the wrong tree (however, I do have this axe...)
Sorry brain stopped working: I meant "IMS" not "CTI". I was refering to their DTD specifications for representing course material. Although from what I have seen it all looks a bit much.
Re. your use of XSLT - I take your point that XML data can be used to generate SQL. I particularly do not agree with your assertion that XSLT is a replacement for CSS. XSLT should (may) be used to produce compliant XHTML which is supported by CSS. Its a matter of maintaining appropriate levels of abstraction - my main observation is that CSS is hard to get good at but its VERY powerfull.
I still cannot see how you would get from an HTML based course, which I see as a final product, back to a Moodle course. However you do it, its a nasty bit of reverse engineering.
Re. your use of XSLT - I take your point that XML data can be used to generate SQL. I particularly do not agree with your assertion that XSLT is a replacement for CSS. XSLT should (may) be used to produce compliant XHTML which is supported by CSS. Its a matter of maintaining appropriate levels of abstraction - my main observation is that CSS is hard to get good at but its VERY powerfull.
I still cannot see how you would get from an HTML based course, which I see as a final product, back to a Moodle course. However you do it, its a nasty bit of reverse engineering.
From what I understand, Howard, Gary is only talking about the course descriptions eg http://moodle.org/course
(Please correct me if I've misunderstood, Gary)
but I agree with Howard that it still sounds like a lot more work than is necessary. The usual way to approach problems of multiple formats is to use a form to enter raw data directly into a database, then use that data to generate your various presentations.
But, hey, if you're having fun playing with XSLT, you're having fun!
(Please correct me if I've misunderstood, Gary)
but I agree with Howard that it still sounds like a lot more work than is necessary. The usual way to approach problems of multiple formats is to use a form to enter raw data directly into a database, then use that data to generate your various presentations.
But, hey, if you're having fun playing with XSLT, you're having fun!
IMS XML...
aha. I had looked at that and found it way more than I needed.
>I particularly do not agree with your assertion that XSLT is a replacement for CSS
I said WHAT??? Oh my gosh. I should never have said that. It is my firmly held opinion that XSLT and CSS work with each other and that is how I use them.
>nasty bit of reverse engineering
Something I do well
aha. I had looked at that and found it way more than I needed.
>I particularly do not agree with your assertion that XSLT is a replacement for CSS
I said WHAT??? Oh my gosh. I should never have said that. It is my firmly held opinion that XSLT and CSS work with each other and that is how I use them.
>nasty bit of reverse engineering
Something I do well
Sorry if I sounded negative, I'm genuinely trying to understand what you're doing ... it's a quite different application of XSLT than I've ever encountered before.
And take anything I say with a grain of salt.
Consider the saying that if your only tool is a hammer, every problem looks like a nail.
Then consider that if you have classes that are in HTML, you can move the classes to Moodle if you can extract the info Moodle needs and add it to the database. That works if you use XSLT or PERL or cut and paste.
I have classes in HTML. I can extract the info needed to describe the classes and put that info in a sql file.
This lets me use the HTML as the 'most valid source'. If I update the HTML, I can easily update Moodle.
I will say more in another message if this is clear. OK?
Gary
Errrr....
Ok, do I take it that you already have a considerable investment in online material that you are trying to find an easy way to move to Moodle?
If that is the case it is very likely that there isn't a way. We looked at this (and some of our material *is* in XML). The fundamental problem is that Moodle imposes (bad choice of word) a way of organising courses that implies a ground up approach. It makes it difficuly to simply "plug in" existing material. That doesn't mean to say though that the excercise will not be worth while. I strongly beleive that the result will be better material.
Also you cannot use XSLT on HTML. You can use it to process XHTML but why? This is backwards.. XHTML is not self-describing data, so how would you write the XSLT?
Ok, do I take it that you already have a considerable investment in online material that you are trying to find an easy way to move to Moodle?
If that is the case it is very likely that there isn't a way. We looked at this (and some of our material *is* in XML). The fundamental problem is that Moodle imposes (bad choice of word) a way of organising courses that implies a ground up approach. It makes it difficuly to simply "plug in" existing material. That doesn't mean to say though that the excercise will not be worth while. I strongly beleive that the result will be better material.
Also you cannot use XSLT on HTML. You can use it to process XHTML but why? This is backwards.. XHTML is not self-describing data, so how would you write the XSLT?
I'm intrigued by your comment: "XHTML compliance is a must."
I have read widely on this topic and found the implications convoluted, to say the least, and that there is certainly no wide community consensus on the issue.
In fact the benefits/costs on both sides seem quite minimal and real-world factors appear to render this point moot for many people.
I could dig up some links on the subject if anyone is interested.
Tying this to the XSLT/smarty discussion, given the stated aim of decoupling presentation, did you perhaps mean that *potential* XHTML compliance is a must."
(for info: I work alongside Howard Miller, the originator of this thread)
I have read widely on this topic and found the implications convoluted, to say the least, and that there is certainly no wide community consensus on the issue.
In fact the benefits/costs on both sides seem quite minimal and real-world factors appear to render this point moot for many people.
I could dig up some links on the subject if anyone is interested.
Tying this to the XSLT/smarty discussion, given the stated aim of decoupling presentation, did you perhaps mean that *potential* XHTML compliance is a must."
(for info: I work alongside Howard Miller, the originator of this thread)
Well, basically, since I have to design templates for every page then I might as well use the current standard XHTML. I'd be very interested to see what arguments you've found against XHTML, as I haven't come across any yet...
If you really didn't like XHTML then you could always design a HTML 4.0 theme
If you really didn't like XHTML then you could always design a HTML 4.0 theme
This is probably the best summary of the pro's and con's though it does get quite technical in places.
http://www.hixie.ch/advocacy/xhtml
http://www.hixie.ch/advocacy/xhtml
Hmm ... interesting and educational link - thank you!
It still seems to me that many of those problems he mentions can be worked around, and in years to come, as browsers improve, will cease to exist at all.
But regardless of this, the idea of templates means that there can be an XHTML template, an "HTML 4 tag-soup" template etc ... so the Moodle admin (user?) can choose whether they want XHTML or not.
Most themes will be simply be modifications to the CSS file (colours, patterns, fonts etc), with the possibility for advanced users to create very different themes by modifying the template files.
It still seems to me that many of those problems he mentions can be worked around, and in years to come, as browsers improve, will cease to exist at all.
But regardless of this, the idea of templates means that there can be an XHTML template, an "HTML 4 tag-soup" template etc ... so the Moodle admin (user?) can choose whether they want XHTML or not.
Most themes will be simply be modifications to the CSS file (colours, patterns, fonts etc), with the possibility for advanced users to create very different themes by modifying the template files.
With regard to using a different template, I don't think the differences warrant the effort of diverging from the majority. Creating a valid (X)HTML + CSS webpage layout that works as expected across a wide range of browsers/screen sizes/devices/people while conforming to accessability standards is tricky enough without splitting your potential developers/users across two competing layouts.
I think the key to the answer is that there is a step between HTML 4 tag-soup and XHTML. Using one of the HTML 4.01 doctypes would give all the benefits of using one of the XHTML 1.0 doctypes, such as being able to validate the output for correctness and working correctly with CSS stylesheets, without any of the drawbacks.
It would also provide an convenient stepping stone if you intend to transition to XHTML gently rather than all at once.
You could, perhaps, move the current HTML into templates as-is, to make for a less daunting initial milestone. This would allow easy access to the parts most in need of a clean-up and you could then set validation, greater use of CSS, and any possible move to XHTML as longer term goals that can be approached on a page-by-page basis and are decoupled from the PHP development and each other (to a degree).
I think the key to the answer is that there is a step between HTML 4 tag-soup and XHTML. Using one of the HTML 4.01 doctypes would give all the benefits of using one of the XHTML 1.0 doctypes, such as being able to validate the output for correctness and working correctly with CSS stylesheets, without any of the drawbacks.
It would also provide an convenient stepping stone if you intend to transition to XHTML gently rather than all at once.
You could, perhaps, move the current HTML into templates as-is, to make for a less daunting initial milestone. This would allow easy access to the parts most in need of a clean-up and you could then set validation, greater use of CSS, and any possible move to XHTML as longer term goals that can be approached on a page-by-page basis and are decoupled from the PHP development and each other (to a degree).
Don't worry, I know about the problems of browser compatibility ... the Moodle you're looking at now is not exactly a 5 minute job.
I agree totally about transition - I have no intention of breaking anything or alienating anyone. XHTML 1.x is a distant goal, but when I say XHTML I've always meant it like it's described here: http://www.nypl.org/styleguide/xhtml/guidelines.html
This is actually XHTML 1.0 Transitional - so I probably should be clearer by using that name from now on.
My main aim is just to clean up my own 1994-based HTML habits and move to consistent lower case tags, quoted attributes, closed tags etc, while removing things like FONT tags. This stuff is not going to cause browser problems. After that, details like doctypes and xml prologues are quite minor (just a line or two at the top).
I agree totally about transition - I have no intention of breaking anything or alienating anyone. XHTML 1.x is a distant goal, but when I say XHTML I've always meant it like it's described here: http://www.nypl.org/styleguide/xhtml/guidelines.html
This is actually XHTML 1.0 Transitional - so I probably should be clearer by using that name from now on.
My main aim is just to clean up my own 1994-based HTML habits and move to consistent lower case tags, quoted attributes, closed tags etc, while removing things like FONT tags. This stuff is not going to cause browser problems. After that, details like doctypes and xml prologues are quite minor (just a line or two at the top).
Came across a very nice templating scheme in Xaraya, which I'd like to keep an eye on and perhaps even use in Moodle.
http://docs.xaraya.com/docs/rfcs/rfc0010.html
http://docs.xaraya.com/docs/rfcs/rfc0010.html
"I have done some work with IMS recently and its *really* nasty!"
Could you please explain the "nastiness"? There's a trend here in Sweden propagating for IMS/SCORM, using the "standards" arguments.
I know this might not be the right forum, but on the other hand it could be useful for Moodle community to know a little bit more about this to be able to come with useful input for the further development of this product.
Cheers
Could you please explain the "nastiness"? There's a trend here in Sweden propagating for IMS/SCORM, using the "standards" arguments.
I know this might not be the right forum, but on the other hand it could be useful for Moodle community to know a little bit more about this to be able to come with useful input for the further development of this product.
Cheers
I have to start by pointing out two things (1) I have only worked with the IMS QTI specification, and (b) I don't have a great deal of background in the IMS world so I maybe missing the point somewhere.
However, the DTD for the QTI has a bit of a design-by-commitee feel. Its designed to do everything and is complex and decidedly tricky. I think that a DTD should be a intuitive as possible, but this has all manner of options many of which have a less than obvious purpose. I think you would be doing well to design a system that exported material out of Moodle and it looked how you expected in WebCT (for argument's sake).
I don't want to be too negative as its almost certainly a step in the right direction.
However, the DTD for the QTI has a bit of a design-by-commitee feel. Its designed to do everything and is complex and decidedly tricky. I think that a DTD should be a intuitive as possible, but this has all manner of options many of which have a less than obvious purpose. I think you would be doing well to design a system that exported material out of Moodle and it looked how you expected in WebCT (for argument's sake).
I don't want to be too negative as its almost certainly a step in the right direction.
IMS/SCORM in Nutshell:
If you talk about SCORM, I ask you which level you choose:
- level one: cut a piece of content out of its context and paste (metadata)labels on it to give it new sense. (core-label-names are lent from DUBLIN CORE, IMS also uses theses)
- level two: take your original course, strip it until you have only the outline and then hang the content back in the tree, but WITHOUT condititions and dependencies, this is how I saw the first draft of the content packaging (CP) proposal from IMS, but absorbed in SCORM.
(I think this level can be useful, but creating standards for it even with XML is hard and moving CP from one eLearning-system to another is still..!@#!) - level three: Here comes the old CBT back on stage: SCORM tried to incorporate the old AICC standard, you know the CBT for training individual pilots...
Depending of your score on modul one you get 2 days later modul 13B instead of 13A.
To connect al these learning-boxes and communicating the conditions SCORM prescribes an old version of JAVA, from the days before SUN and Microsoft grow apart..
It is a very detailed filtering system for optimal individual learning. Learning in a group cannot be designed inside SCORM, unless you simulate all the others in the group.
(Learning design form IMS can design group-activities but is under development) - Describing a system like level three, asks for a another system to control all that: This system must have knowledge from the local educational system and all its business-rules: SCORM does not deliver a solution for that... (IMS only has a draft , I think SABA came most close with their catalog-approach.)
- If you want to design these very complex IF THEN ELSE learning-paths, you need lots of time an money.
- Most teachers and professors are not composers but arrangers. take an outline, change a little bit, kill a resource, past another and TUNE TUNE TUNE it for the students of this year. Next year another group, another arrangement!
- import/export of complete course-outlines between - for example BlackBoard and Moodle - doesn't make sense: the educational design behind these two are not identenical, so you only will exchange the things that are in common: poor, very poor.
- Of course would it be nice to have import/export filters for stand-alone-exercises. If you now how exercises have structure(!!) in another eLearingsystem, you could map it on a Moodle test-structure and then let it be part of the student-monitoring. (like the Blackboard import.) ..............could XML help here with the structure-transform process?
Here's an interesting resource with advice on using transitional XHTML, CSS and table-based designs from some of the people behind the NYPL site mentioned earlier.
The two sample chapters are well worth reading and I would recommend buying the book to anyone interested in web design.
Geez, never mind the book where DID he get the hat from? 
No seriously, I'm quite enjoying Ian Graham's XHMTL 1.0 language and design sourcebook. It ain't new but it's a nice solid read. It's comforting to read a three year old book that's still cutting edge!
No seriously, I'm quite enjoying Ian Graham's XHMTL 1.0 language and design sourcebook. It ain't new but it's a nice solid read. It's comforting to read a three year old book that's still cutting edge!