Skip to content.

The E-Learning Framework

Sections
Personal tools
You are here: Home » ELF Project Directory » Course Information Group » Options for Authoring Curriculum Content

Options for Authoring Curriculum Content

Download this report by Ian Martin from the Open University, as a landscape PDF document

Introduction

This report discusses the requirements for an authoring tool to help users in the process of creating documents that adhere to a particular structure. This tool will be primarily used to help create XML documents conforming to the eXchanging Course Related Information (XCRI) schema that defines a generic course description specification for the UK. However, ideally, it should also be able to function as a useful tool in a variety of different scenarios that require the production of structured documents. This report explores the requirements of the XCRI scenario and compares these requirements with the experience of authors in other structured authoring environments. The features of a selection of currently-available and soon-to-be released tools are examined as they attempt to meet the envisaged requirements of the XCRI scenario. The overall objective of this research is to both draw attention to the tools' varying strengths and weaknesses by means of a comparison and also to use this comparison as a learning exercise to further refine the initial structured authoring requirements for the XCRI project.

At this stage, the inherent subjectivity present in a report by a single author has been mitigated by reference to previous evaluations of structured authoring tools and the recorded experience of others. Notwithstanding this, it is suggested that looking forward there may also be a need for some formal usability trials involving a spectrum of potential users in a variety of different use cases. This should ensure the most objective perspective is reached and also serve to fully capture the functional requirements of the system should a software engineering exercise be required. However, such a formal usability study is out of scope of this report.

The functional requirements of the tool are vitally important, but technical requirements such as cross platform availability, extensibility, and adherence to standards are also crucial to ensure the tool affords maximum flexibility across a wide number of heterogeneous organisational environments. Cost will also likely be a key consideration, although the budget is unknown at this moment in time, and any comparison must factor in the initial license cost and some indication as to those factors that may increase relative total cost of ownership (TCO). Some of these factors may include, but not be limited to, costs incurred or saved as a result of extra hardware/software, training, the quality of existing documentation, support, upgrades, and program reliability. As we move from the tangible to some of the more intangible costs and benefits a scorecard that attempts to formalise and weight these pros and cons could be considered useful. However it must be borne in mind that the aim of this report is exploratory and not to produce a clear winner from a selection, but rather to generate more detailed thought and discussion about how an ideal tool might perform.

The need for tools

One of the big advantages of the XML standard is that it was designed to be human readable as well as machine readable. So if authoring XML documents can be done using a standard text editor then why should we need the help of a structured authoring tool at all? Because, in practice, although XML documents are human readable for all but the most simple of XML documents tools can help make the authoring process easier and quicker. They can do this by managing some of the complexity surrounding what constitutes a well-formed and valid document and so prevent errors and reduce the time spent 'debugging'. Auto-completion of matching ending tags and auto-suggestion of tags and attributes dependent on context not only helps reduces typing errors but also acts as a useful memory aid for the experienced user, or even as a learning device for the novice.

Indeed, before we even begin the process of editing and are simply reading an XML document, highlighting tags to differentiate them from content and indenting documents according to their hierarchical structure can aid document navigation and readability. A simple text editor that also performs these functions for an XML document could be said to be XML-aware. Even from this fairly humble starting point a simple tool can result in significant productivity gains. For example, see Miara et al. (1983) and Rambally's (1986) studies involving novice and expert programmer comprehension of indented and colourised source code. It is reasonable to assume here that the productivity gains they report would also apply to the comprehension of XML source.

By way of example, take a look at Figure 1. This shows a side-by-side comparison of the same XML document in two simple text editors. The first is in Notepad that comes shipped as a default accessory with Microsoft Windows. The second is in Notepad2 an open source (GPL-licensed) replacement that can colourise and auto-indent code. From the screen shots it can be seen that the indented and colourised XML immediately appears a lot more pleasing to the eye and instantly more navigable.

Screenshots giving an XML readability comparison between Notepad and Notepad2 on Windows XP

Figure 1: XML readability comparison between Notepad and Notepad2 on Windows XP

At this early stage, however, it is important to flag that a typical user of an XML authoring tool may not be a programmer and may not even need to worry about syntax highlighting, auto-indentation and 'debugging'. After all they may never want or need to see the XML source and would perhaps only be concerned with the look of the finished document. The primary objectives of their work task may only be that all the required document elements are filled in correctly and that they are arranged in a familiar and pleasing format on the page. The tags and the neatly indented structure of the source could be irrelevant as long as the tool functions correctly and helps them achieve their desired outcome. This final outcome in terms of human readability may simply be a document that looks and functions as expected whether that be in printed, PDF, mobile or web format. These requirements for the 'average' user may necessitate either hiding the XML source view from those users who do not wish to see it, or not providing those users with a facility to edit the underlying XML data structure at all.

So initially although I made the case that for small XML authoring tasks maybe a simple text editor was all that was required, I know add the caveat that a text editor will suffice if the user is comfortable with the syntax of XML and the structure of the document. Some users may be confused by the appearance of the tags and unsure how they relate to the document's structure. Not only may the learning curve not be worth tackling because of the training cost versus benefit, but allowing this low-level of editing may pose an unacceptable level of risk should editing errors occur. In the case of such errors the documents may remain human readable, but they will most definitely not be machine readable. In this case a tool could also help by checking that a document is correct, i.e. well-formed and/or valid, before allowing the document to be saved. A useful editing tool could highlight these potential problems and possibly prevent their occurrence, but it may be that a completely different approach that presents a forms-based interface to the user is a more suitable alternative for some types of structured authoring tasks.

Form input as an alternative to editing

For some short documents a form-filling approach rather than a full scale editing task may be sufficient. Using forms can completely remove the user's need to worry about the mechanics of editing an XML document, its readability, and the integrity of its underlying structure. Instead the user can concentrate on replying to form prompts in order to provide timely and accurate data. The W3C recommendation, XForms, provides an open-standard data format for such an approach. Implementation of this standard via an XForms engine has seen some activity although it should be noted that the standard is still in the fairly early part of its life cycle and currently has not seen much activity in the way of browser-based adoption. XForms has been designed so as to remove with the need for much of the form validation and processing that is done with client-side or server-side scripting languages such as JavaScript and PHP at the moment. Currently Firefox has an XForms plug-in at version 0.6. It doesn't look likely that Internet Explorer will provide XForms support due to Microsoft's promotion of Infopath as a superior alternative to forms-based information gathering.

If XForms could be criticised as being not quite ready yet in terms of browser support then perhaps the XForms engines that 'translate' the request for an XForms page into XHTML, Javascript and CSS so that it can be readily understood by the current batch of browsers is a realistic alternative. This translation can be achieved by server side processing or a combination of server-side and client-side processing in the manner of an Ajax application. Of the current clutch of XForms engines that operate in this manner, formsPlayer and Orbeon Inc.'s open sourced Orbeon Presentation Server (OPS) both look promising. Although a review of the available XForms engines is not in scope, it could worthwhile to build a small prototype using this type of technology in order to test the functionality of an XForms approach to structured authoring. This may provide a viable alternative to the XML editing approach.

Although the XForms engine approach offers a workable cross-platform solution today, it should be borne in mind that this approach will require the user to have an Internet connection to a server or to be running their own local web server in order to author even the most simple structured documents. The former may not be compatible with some use case scenarios and the latter may pose an unacceptable risk within an organisational infrastructure. A way of accessing XForms both online and offline is to use an enterprise level product such as Oracle Application Server which has support for a rich variety of mobile devices in both online and offline modes. Also competing in a similar market space is IBM's Workplace Forms that integrates well with their own Lotus Notes with its impressive replication facilities. Another approach to offline authoring with XForms can be see in the open source rival to Microsoft Office, OpenOffice.org's 2.0, which contains an integrated implementation of the W3C's standard. Again there may be some merit in a prototype approach to see if OpenOffice.org and XForms provides a stable enough framework for a structured authoring environment. Note that this will require the installation of another office suite, or at the least word processor, that although has a zero initial purchase price will have costs associated with training and support. Microsoft Office is still currently far and away the most popular choice for desktop productivity software.

As previously indicated, Microsoft themselves have eschewed the XForms standard and instead have used a variety of open standards including XML, XSD, XSLT and XPath to build their own information gathering application called Infopath. Infopath is a mature, user-friendly product with online/offline capabilities and 'silent' forms version control. Although the Infopath engine will only run on the Windows operating system, because it is built on top of so many open standards integration is possible with a wide variety of heterogeneous environments. Adobe also have a competitor to XForms called XFA Forms but, despite Adobe dominance with the PDF standard for electronic documents, this does not appear to be the serious rival to XForms that Microsoft's Infopath is at present. Tavis Reddick at Fife College has been working with Infopath and the XCRI schema in order to allow Marketing personnel to have a single, easily-editable source of course descriptions.

Integrated tools

As we begin to analyse what functions a tool could usefully perform, and how different types of user may have different requirements of the same structured authoring task, it is worth raising that one tool may not necessarily have to fulfill all functions. It may be that a selection of tools in the form of a tool set, with varying degrees of integration, can provide a solution that is satisfying and sufficiently flexible. One user may use a text editor to edit the XML document and then call upon an external XML processor to check for well-formedness and/or validity. An integrated tool set could make this call to the external processor automatically at the right time and may also allow for substitution of the processor and other constituent components should the need arise. This 'pipelining' type approach is common in Unix environments and whilst it doesn't suit the novice well, it is a concept that can prove very powerful in the hands of a power-user/programmer.

A complimentary idea is that of a core tool that can be enhanced to meet different requirements via a series of plug-ins. It thus becomes a universal tool. A popular example that has been very well received amongst the programming community is the Eclipse Integrated Development Environment (IDE). It is open source and there are a wide variety of plug-ins available to support programming in a number of different languages. Because of the universal nature of the tool there are also plug-ins  available that support structured authoring. These include XmlBuddy and, perhaps the most popular and mature, the Web Tools Platform (WTP). XMLBuddy is a commercial product that comes in two flavours, a pro and a 'lite' free version. The features available in the free version are limited in comparison to the WTP plug-in which is fully featured and also free both in terms of purchase price and in the sense that it is open source. Figure 2 below shows an example of an XML document opened in Eclipse with the WTP plug-in.

Screenshot showing Eclipse with WTP plug-in

Figure 2: Eclipse with WTP plug-in showing document source view

Eclipse WTP provides a convenient structured authoring environment for those comfortable with Eclipse, but a more than moderate learning curve for newcomers. Eclipse's strength is its extensibility, but this is at times its greatest weakness. A plethora of at times counter-intuitive menu options and multiple docked and tabbed windows can bewilder the newcomer. If a user accidentally closes a window or tab it can be a real challenge for the newcomer to work out exactly how to open it again. Eclipse is a Java application and as such is supported cross platform, however perhaps because of its Java architecture it is also very resource hungry. Eclipse WTP has much potential, but does not seem sufficiently mature for the casual user at thus moment in time. For instance, the outline view to the right in Figure 2 should allow drag and drop of elements for repositioning, but doing so seems to result in an error that can only be resolved by restarting the program. The design view seen in Figure 3 presents a variation on the forms based interface discussed previously and this presents an editing view with which the casual user could potentially be more comfortable.

Screenshot showing Eclipse with WTP plug-in in design view

Figure 3: Eclipse with WTP plug-in showing document design view

Eclipse and the WTP offers much potential as a base for a customised structured authoring environment. Its cross-platform support, extensibility and growing adoption as an industry standard make it a sensible strategic choice if the user base is predominantly made up of programmers. For other users to be comfortable the interface requires simplification --this may be possible with some dedicated plug-in development-- and those resource demands will prove challenging for older desktop/notebook machines with requirements to run other programs simultaneously.

Another integrated tool set that is a Java application with its beginnings as a programmers text editor is jEdit. This is considerably less demanding in terms of system resources than Eclipse yet still provides good support for XML editing.  A series of plug-ins currently available available in 0.x versions for XML, XQuery, XSLT, and XPath amongst others are offered. Figure 4 shows jEdit's intuitive content assist feature that seems to work a little more reliably than that of Eclipse at this moment in time. Like Eclipse its interface is designed more with the programmer in mind rather than the casual user, but it is far less demanding of system resources. The differences between jEdit and Eclipse are reminiscent of those arguments often touted during the (still-ongoing) editor wars between vi and Emacs. vi and jEdit are both lightweight, powerful and suited for taking out of the toolbox to perform most editing tasks; Emacs and Eclipse however are heavyweight environments that users 'live in' where they can perform almost any task - editing or otherwise.

Screenshot showing jEdit with XML plug-in

Figure 4: jEdit with XML plug-in running on Mac OS X

Tools help produce well-formed and valid documents

In order for an XML document to be correct it must be both well-formed and valid. A well-formed document adheres to the following rules as defined by the W3C XML 1.0 recommendation:

  • one, and only one, root or document element
  • non-empty elements are delimited by a matching case-sensitive start and end tag
  • empty elements may be marked with an empty element tag, e.g. <label/> or <label />
  • all attribute values must be quoted
  • tags may be nested but must not overlap
  • XML documents should begin be with an XML declaration that specifies the XML version being used, e.g. <?xml version-"1.0"?>

Figure 5 shows an example of a text editor that is able to check for XML document validity. In the example below the tool helps us by drawing attention to an invalid tag by underlining it in red. In this case the closing tag does not have the same case as the opening tag. Note that with this text editor, Emacs running in nXML mode, we are not prevented from saving the document if it is invalid. Emacs makes the assumption that the user knows what he or she is doing. This tool does not attempt to prevent us from making mistakes but rather helps and encourages us not to make them.

Screenshot showing EMACS in nXML mode highlighting malforned XML

Figure 5: Highlighting malformed XML in Emacs nXML mode on Mac OS X

So that's the rules concerning well-formed XML documents, but what about valid XML documents? A valid document must conform to an external document type definition that specifies the grammatical constraints on a document over and above those of well-formedness. These constraints include what tags are permitted and required and in what context, together their attributes and any default values.

Although the initial W3C XML 1.0 recommendation specifies that this be done by way of a DTD, other mechanisms have been gaining in popularity over the last few years. One of these is another W3C recommendation, the XML schema language which allows for a more expressive than DTDs and expressed in XML. Other alternatives with varying degrees of popularity include RELAX NG that has both an XML syntax and a more compact non-XML syntax. RELAX NG is a standard maintained and  promoted by the Organization for the Advancement of Structured Information Standards (OASIS) who are a player in the development of e-business and web services standards. Also worth including is schematron a 'language for making assertions about patterns found in XML documents' which can be used in conjunction with other schema languages and DTDs.

The XCRI project uses XML schema language (XSD) as do many of the newer projects using XML for document structure, but this should not preclude an exploration of our tools support for the other schema languages above. We may consider support for XSD validation to be essential and support for the others to be desirable; it's worth noting that some standards such as schematron are used in conjunction with others rather than as a replacement.

So in order to try and ascertain the best tool for the job, let's examine a structured authoring case study and provide commentary on the usefulness of tools in the authoring process and highlight any limitations.

Case Study: Authoring course related information at the Open University

The Open University in the UK currently uses Microsoft Word as the standard for its document production process. Word documents are created by block authors and then passed to editors for editing using Word's track changes feature. After the authoring/editing cycle is complete then printed output in the form of a study guide book is produced for the majority of courses, although some online-only courses make use of PDFs as a more economic alternative. I should explain some of the terminology here in that a block is a discrete chunk that makes up a course, often this used to be a book's worth. A course itself is anything from a 10 to 60 CAT point chunk of learning that students can enroll upon and for which they are assessed and awarded a grade on completion. Multiple courses are combined to make up a degree award.

The Open University is moving towards a new structured authoring environment that will allow for re-use of course materials and distribution of the same content via number of different media channels. Because of the authors', reviewers' and editors' familiarity with Microsoft Word, the university have decided to use this as their structured authoring tool to produce well-formed and valid XML. Typically the final documents will be long (5000 +words) although it's unclear as to this document will consist of one single source or be sourced from multiple files. A discussion of the merits of Microsoft Word as an authoring tool follows at the end of this section, but for now a selection of tools will be employed to perform the authoring function in place of Word and notes are made below on their effectiveness. In the following evaluations a short XML document was first created in Microsoft Word and then loaded into an alternative editing environment.

Alternative 1: A plain text editor with syntax highlighting (e.g. TextWrangler) and a separate validator (e.g. XMLNanny)

These tools are not integrated, but each definitely provides a baseline set of help to the authoring process and are intuitive for the first time user. Neither require Internet connectivity or any web server software on the client. However although XMLNanny provides a validation interface into the Xerces and libxml2 parsers that is fairly intuitive, it lacks any real time well-formedness and validation features. So typically a user is forced to work in a kind of batch mode where changes are made with the text editor and then the validity of these changes are reviewed by running the XML document against the associated schemas by way of XMLNanny. This combination of tools was definitely of some use, but it was unable to cope with multiple XML name spaces and validation of the numerous occurrences of styling markup introduced by Microsoft Word. These tags that were more about style than content were a constant thorn in the side of alternative authoring tools and the ability to introduce all sorts of styling information into the XML document is something that needs to be seriously questioned.

Alternative 2:  An XML aware editor (e.g. Emacs nXML, Eclipse, jEdit etc)

Emacs is a text editor that provides real time well-formedness checking of XML documents and with the addition of the nXML plug-in also real time validation. However at present only RNG schemas are supported and users wishing to validate against other schema types must convert them into RNG using a tool such as trang. This is achievable, but only seems a sensible option for those users who prefer Emacs above any other editing environments. It is however available cross-platform.

Eclipse looks promising in that, in addition to the familiar source and outline views, it also offers a visual way of building up XML documents for an associated schema. Unfortunately there were some serious usability issues with the tag autocompletion and context awareness in my evaluation. This coupled with the resource hungry nature of this Java application and its at times over-complicated interface make it difficult to recommend at this stage in its product life cycle. There is certainly potential for a cut-down and customised version of eclipse that is dedicated to structured authoring, but this will require significant development effort that could perhaps be best spent designing something from the ground up.

Of all the XML aware editors, jEdit appeared to work most smoothly. It handles schemas in RNG, XSD and DTD format, but like all the other tools in this review had issues some with multiple name spaces and  Microsoft Word XML styling tags. It provides nice, quick and usable context sensitive insertion of valid XML tags and attributes based on associated schema, but does not have a WYSIWYG interface. For the programmer it offers an intuitive, cross-platform, cheap, and readily-available solution for most structured authoring tasks. It works well with a single unshared document, but it offers no collaboration facilities over and above the asynchronous version control of CVS.

Alternative 3: Microsoft Word 2003

Microsoft Word provides a familiar environment for the casual user. This is not a cross platform solution (although Microsoft produce a Mac version of Word, it currently offers no XML authoring support and there is no version for Linux), but because of Microsoft's dominance of the desktop productivity software and operating system market it is likely that most organisations will already have a Word for Windows installation and license. This makes the transition to XML authoring with Word not only a relatively easy one, but also a cheap one for the majority. Figure 6 shows a screen shot of XML authoring in Microsoft Word.

Screenshot showing XML authoring in Microsoft Word 2003

Figure 6: XML authoring using Microsoft Word 2003 running on Windows XP as guest OS on Mac OS X running Parallels

Although the user is undoubtedly presented with a familiar word processing environment, there are a number of usability and technical issues that require addressing in order for Microsoft Word to be considered an ideal structured authoring environment. Firstly, because XML is about content rather than style, it seems at odds that Word allows users to apply all sorts of style formatting to an XML document which results in a plethora of Word-specific style tags in the document source. These tags are not visible in the way that the XML elements appear in the figure above. These style elements then clutter up the document and make it difficult to subsequently port the document to other editors which seems to defeat the open nature of the XML standard. This may be intentional.

Also, editing documents without styling them should ideally be a keyboard focused task. So it's particularly inconvenient to have to use the mouse to insert tags rather than by context-sensitive auto-suggestion at tag open (<) that the other editors in this review provide. In Word having to use the mouse to selecting the paragraph tag from the XML pane to the right is particularly tiresome. This XML pane also includes a hierarchical map of the document's structure, but Word does not indent the document itself according to structure in the manner provided by other editors.  As such document navigation can be at times confusing. Asynchronous collaboration however is facilitated by Word's 'track changes' feature.

Microsoft Word, certainly in its 2003 incarnation, unfortunately appears to fall short of being a true WYSIWYG (What You See Is What You Get) XML editor. It also falls short of being a WYSIWYM (What You See Is What You Mean) editor like jEdit or Eclipse. As such, although it does provides a familiar document authoring environment for users, it has some shortcomings that require addressing from both a technical and usability perspective if it is to be an acceptable structured authoring environment. In order to be a true WYSIWYG XML editor then the user would be presented with the finished, styled, document and editing would be possible in that view with the effect of any changes immediately visible. Word does allow for the use of a preview function, if you write your own VB macros, but this is a non-editable preview. It may be that the beta release of Microsoft Office 2007 gives an indication of Microsoft's direction with this product, but this was not available for evaluation at the time of this report.

Alternative 4. A dedicated XML editing environment (e.g. Altova's XMLSpy)

Altova's XMLSpy currently leads the pack of dedicated XML authoring tools. It provides a rich environment, but one that is primarily aimed at the programmer or power user. It shares much in common with Eclipse in this respect, but the professional 2007 edition has a single-seat license costing some €399 and is only available for the Microsoft Windows platform. Pre-2007 versions have offered a less feature rich 'home edition', but this option does not appear to be currently available in the 2007 version. XMLSpy is undoubtedly a more mature product than Eclipse or jEdit for XML authoring tasks and this is more than likely a result of it being a dedicated XML tool rather than providing this functionality through a number of plug-ins, however it is difficult to justify the initial cost and TCO for a tool that has only potentially limited benefits for the authoring of course related information.


Summary

None of the selection of currently available tools provides a comfortable fit with the envisaged requirements for structured authoring in the XCRI scenario. The market is still fairly immature and the best of the bunch appear to be split between those tools designed with programmers in mind, such as Eclipse, jEdit, and XMLSpy and those that see the end user making up their primary market, e.g. Microsoft Word. Whilst the former come closer in terms of technical requirements, they pose a serious usability challenge to the non-programmer. The latter is certainly usable by someone comfortable with Microsoft Word, but currently produces a technically less than satisfactory end result making porting the finished document to other authoring environments difficult. This may not be an issue for those organisations who are comfortable with Microsoft Word as a homogeneous solution, but it does appear to defeat the open nature of the XML standard somewhat.

An alternative forms-based approach has much to offer as a solution for the authoring of course relation information. It is recommended that prototypes using either Infopath, XForms in Open Office, or native XForms are created in order to test the viability of this approach. With this in mind, it is also interesting to comment upon the current activity in terms of Web 2.0 word processing and office applications. It would seem that the time was ripe for a Web 2.0 structured authoring environment. Currently no one appears to offer a Web 2.0 XML editor (eWebEditPro+XML looks like an XForms-based approach). Initial evaluations of Google Docs and Zoho Writer show great potential for collaborative document authoring - albeit in an online-only mode. Thinkfree is also very powerful and in its Java power-edit version is very similar to MS Word but with an online/offline model available at extra cost. This online/offline capability refers primarily to document storage rather than document linkage which is seen as a requirement for XCRI. That is, if we were to link one fragment of a document to another we would need the latest copy of each offline. Lotus Notes (its creator Ray Ozzie is now a key figure at Microsoft  and is reshaping their approach to office applications) had this smart caching functionality and essentially you synchronized your local copies of documents every time you went online. The First Class desktop conferencing software used at the Open University presently does a similar thing.

This requirement for an online/offline mode of working is a challenge thrown up by the limitations of working with online-only resources that's commonly referred to as the horizon of connectivity. Operating beyond this connectivity horizon is something that email clients seem to have fairly well sorted via POP, and IMAP to an even greater extent, but for document authoring (not just structured document authoring) this problem has yet to be convincingly solved. In some senses the ever more ubiquitous nature of wireless Internet access is making this less of an issue, but still there are scenarios involving travel where offline access is a requirement. On the open source front, Zimbra is making inroads to this with their collaboration suite, and Live Document's solution for Word and Excel collaboration provides a Windows-only solution. Microsoft's recently-acquired Groove technology, currently in preview in MS Office 2007, looks to superseded this on release. Scrybe also looks an outstanding newcomer when the application launches. Although it is not a structured authoring solution, it appear to have a smart approach to online/offline working and looks like it may offer many fresh ideas for new ways of working in the world of Web 2.0.

References

Editors

Notepad2 - an open-source notepad replacement

EMACS nXml mode

Eclipse

Forms based information gathering

W3C XForms 1.0 (Second Edition) recommendation

O'Reilly's XForms Essentials [online version]

XForms in Open Office 2.0

formsPlayer - the XForms toolkit
Orbeon - Form-based web applications using XForms and Ajax

Oracle's XForms mobile browser applications

IBM developerWorks - Workplace Forms

Microsoft's Infopath home page

XForms and Infopath comparison at xml.com

Top 10 XForms engines at xml.com

Mozilla's XForms extension for Firefox etc.

Ektron's eWebEditPro+XML browser-based XML forms editor

XForms functionality in OpenOffice.org

Collaboration

Live Documents

Zimbra

Microsoft Office Groove 2007

Source code readability

Miara, R. J., Musselman, J. A., Navarro, J. A., and Shneiderman, B. (1983). Program indentation and comprehensibility. Commun. ACM, 26(11):861–867.

Rambally, G. K. (1986). The influence of color on program readability and comprehensibility. In SIGCSE ’86: Proceedings of the seventeenth SIGCSE technical symposium on Computer science education, pages 173–181, New York, NY, USA. ACM Press

Definitive documents

W3C XML 1.0 recommendation

W3C XML schema requirements

RELAX NG specification

Schematron specification

Miscellaneous

http://www.xmetal.com/en_us/support/trial_software/index.x

http://www.stylusstudio.com/

http://www.altova.com/download/xmlspy/xml_editor_enterprise.html

http://www.oxygenxml.com/

http://ahds.ac.uk/creating/information-papers/xml-editors/

http://www.thaiopensource.com/nxml-mode/

http://www.baccoubonneville.com/index.php?option=com_content&task=view&id=36&Itemid=56

http://devresource.hp.com/drc/tutorials/gef-xml/index.jsp

http://it.slashdot.org/article.pl?sid=06/09/08/1839208&from=rss

http://webdesign.about.com/od/htmleditors/tp/aatptextedwin.htm

http://www.elframework.org/projects/xcri

Created by stubbsy
Last modified 2006-11-08 01:55 PM
Funding Partner
JISC Distributed eLearning Strand
« May 2012 »
Su Mo Tu We Th Fr Sa
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Files and Documents
Implements services
Related ELF services
No files or documents.