This schema file contains types which are common to many of the different schemas used by the DEMML system. It has no target namespace so, when it is included in another schema document, it will take on the namespace of the including document.

This is the first alpha version of the DEMML(tm) schema for content (version 0.1). This schema is far from complete and the structure may need to be modified considerably in order to incorporate all the features of the DEMML(tm). While I plan to make future versions of this schema a semi-open standard in the future, the entire schema is currently copyright (c) 2010 by Grant Sheridan Robertson. It is currently not permitted to use this schema - or any portions thereof - in any manner without written permission. However, if you write, I will probably give permision. I simply want to keep track of what is being done with DEMML(tm) so I can keep a handle on it till it is ready for release.

To learn more about this DEMML(tm) go to www.demml.org. To learn more about the schema itself (past, present, & future) as well as a general description of how the DEMML system is organized see www.demml.org/standard/.

Necessary to enable use of the xml:lang attribute. Every DEMML content file will contain a fileInfo element at the top to indicate information about the file as a whole. Any elements declared using this type should be called 'fileInfo' When the RevInfo type is used for the fileRevInfo element then that info pertains to the file as a whole. If any content for any of the items within the file is updated then the fileRefInfo/contentRevInfo element should be updated. Similarly if any of the metadata for any of the items within the file or if the file's metadata (exclusive of the fileRefInfo/contentRevInfo element) is modified, then the fileRefInfo/dataRevInfo element should be updated. This is the person who created or compiled the file. Not necessarilly who created every item within the file. The topic ID is used to uniquely identify a DEMML topic. It is used both to lable specific topics as well as to refer to them. When used to label a topic within the Topic Info file there must be one topic title for each of the language-specific stem folders in the topic folder. When used to indicate the topic in which a DEMML content file belongs, the topicID must include a descriptive title in the same language as the topic stem-folder in which the file belongs or resides. However, one may provide optional additional titles in other languages if desired. Remember, the title is purely for human consumption. All software must use only the topicCode and topicSN to refer to and index the topics.

This is the Distributable Educational Material Classification System (DEMCS) classification code. This code includes the full path to the topic within the DEMCS. See http://demml.org/standard/classification/ for more information.

Do not include the demml:// protocol prefix in the value for this attribute.

The Topic Serial Number must be unique among all the topics within the entire DEMML system. Serial Numbers are assigned sequentially as each topic is added the DEMCS. In case some topics need to be rearranged at some time in the future (hopefully very rarely) the serial numbers can be used by software to locate the correct topics and update their locations within individual users' databases of DEMML content.

In DEMML all content is stored within "Items" which contain both the metadata about the content and the content itself. All items about a particular topic are stored in the appropriate language stem folder under the topic folder. However, it is possible for an item to be associated with more than one topic. In that case the item will be stored under the most closely associated topic (or the topic closest to the root of the tree, or just choose one at random). More than one item can be stored in a particular DEMML content file but all items in a file obviously must be associated with the same topic in order to meet the above requirement.

DEMML items can be of various types. Most important are the Fact-Items which state one of the facts that must be learned about the topic. Fact-Items should be concise and to the point. Explanation-Items are items which explain something within the topic. This is where most of the learning takes place. An Explanation-Item can explain a fact or even why a particular answer is right or wrong. There are Question-Items and Answer-Items as well as Problem-Items and Solution-Items. There can be questions about one or more facts or even about one particular explanation. Explanations can be about almost any other kind of item. However, there should never be questions about explanations which are already about some other question or answer. One has to draw the line somewhere.

While most XML developers have become accustomed to mirroring the hierarchical structure of their data within the XML document itself, DEMML takes a different tack for the structure of items within a topic. One of the primary goals of DEMML is to allow easy distribution of the content in the form of relatively small files. This way a student does not need to download (or copy) and store much more than they really need and the transfer will be as efficient as possible. In addition, there is the possibility of there being hundreds - or even thousands - of items within a topic, especially when you consider all the different problems, solutions, and explanations for those solutions for a single mathematical concept. Therefore, it is not reasonable to attempt to store a topic's entire structure of items within one XML document.

All this means the structure of the relationships between DEMML items is a limited sort of directed graph with the references pointing backwards. Rather than have each fact contain a reference to every question about that fact, as many software developers are accustomed to seeing, it is far more efficient to have each question contain references to the few items that question is about. This way the Fact-Items do not need to be updated every time a new Question-Item is published. All a user has to do is copy the file with the Question-Item into the appropriate folder on their computer (which can be done automatically by some software) and the software can read the file and update its internal database.

Any time an element is declared using this type it should be called 'itemID' Each item must have a descriptive title in the same language as the topic stem-folder in which the item resides. However, one may provide optional additional titles in other languages if desired. If the item is a question or problem then the title should not give away the answer, just in case some software chooses to display the titles of each item. This is simply a sequentialy assigned code number comprised of digits and capital letters. It must be unique among all the other items in the same topic folder. This attribute is for informational purposes only, rather than to define a datatype. It is included so when an itemID is used in a reference, software or human readers can tell what type of item is being referenced without retrieving that actual item. Each DEMML topic contains one or more facts. These are the tiny pieces of information that just wouldn't make sense on their own. A fact is one of the many special types of items. For each fact there could be more than one way to state that fact. All the different ways to state the same fact will each be in their own individual items but will all have the same fact code. This way software can allow students or teachers to choose the way of stating that fact that makes the most sense to them. Any elements created from this type should have the name 'factID' Each fact must have a descriptive title in the same language as the topic stem-folder in which the fact-item resides. However, one may provide optional additional titles in other languages if desired. Because each fact is contained in a separate item, the Item Title for the item containing the fact shuld be the same as the Fact Title. Fact codes consist of one or more digits or capital letters suffixed by zero or one lower-case letter. The first letter is always a capital 'F' to make them easier to recognize when written down. In order to allow additional facts to be inserted into an ordered list of preexisting facts, fact codes follow the same rules and pattern as the DEMCS coding system (see http://demml.org/standard/classification/4-assign_codes.htm). In some cases one level of sub-facts will be appropriate. In which case the sub-facts will have the code of the parent fact followed directly by one lower-case letter. For instance, N7b or 3La. If at any time one feels it necessary to create a third level of facts then serious consideration should be given to creating sub-topics instead, putting each of the primary parent facts in its own topic. Sometimes the order of facts will not matter. But for some topics where the order the facts are listed helps provide meaning to these facts then make sure the facts are numbered in an appropriate order. Fact F0 is the statement of the main point of the topic. There can be only one effective thread with the same threadCode in any one branch of the DEMCS tree. If there are threads with the same threadCode in more than one level of the same branch of the tree, the thread in the branch farthest from the root of the tree takes precedence. This allows a type of inheritance in that a thread can be more general closer to the root of the tree but then be modified to be more specific to the topics in the branches farther out from the root. There is no formal mechanism for controling inheritance. Whichever thread is referenced is the thread that will be applied to the referencing item. The thread serial number should be unique in the entire DEMML system. Used to specify a learning style and how well this item fits that learning style. According to Wikipedia there are as many as 71 different "learning style" models, none of which has been proven valid in any way (Pashler, H.; McDaniel, M.; Rohrer, D.; Bjork, R. (2009). "Learning styles: Concepts and evidence". Psychological Science in the Public Interest 9: 105–119. cited in: http://en.wikipedia.org/wiki/Learning_styles#cite_ref-pashler_1-2). However, this element is made available for those who either subscribe to the Learning Style theories or simply want to provide more information about their content. At the very least, software can use these tags to ensure that students get a good mix of content based on different learning styles for any particular topic or fact. Optional explanation as to how and why this item fits this learning model. Reflects the date and version for this file or item. If this is the first version then the version should be 1.0 and the dates should match the createDate attribute of the fileRevInfo element. This data should only be updated if the actual educational content that the student sees is updated. If only the metadata changes then do not update this element. The data in this element should only be updated if the metadata for the item or file has changed (exclusive of the contentRevInfo element). If only the content has been changed then do not update this element. Date the file was first created. Once the file is created, this date should not be changed. When listed as part of a prerequisite, a proficiency value refers to how well the student must know the specified topic or fact within a topic. In addition, the estimated time to master (etm) attribute should be eiter set to "PT0S" for zero seconds or left out. More than one proficiency can sometimes be listed with a different estimated time to master (etm) for each proficiency level. There is no need to list more than a few different proviciencies as software will normally be able to extrapolate the etm values for various proficiency levels. Multiple proficiencies should be used when a subject, topic, or item has a much steeper "learning curve" for the more advanced material than one would normally expect. Contrary to what one may think, the percent value for some measurements could go above 100% due to either over-study or learning more sub-topics with more proficiency than required by a DEMML syllabus. This is the standard percentage value from 0 to 100. Average Expected Time to Master: This is the average time to reach the specified level of proficiency. It is based on the assumption that the student exactly meets all of the prerequisites for this item or topic but has not studied any of the item, topic, or its sub-topics yet. The duration should be set to a reasonable value. If aETM is not given then software is expected to ignore the etm for this item or rather than attempt to force the student to learn the item in zero seconds. This pattern should limit the aETM to being expressed in minutes only. Naturally, the aETM shouldn't be less than zero minutes. ToDo: Look up or create a more detailed PersonInfo type to use here. This type allows either a simple tokenized string or any URI. It is used for fields wherein some document creators may want to just just a standardized value and others may want to use a URI to provide more specific information. A reference is used to point to some other item. There are various different types of references to point to various different categories of items. This datatype is an empty, abstract datatype. It exists solely to indicate that all the different types of references are of one family. Though it would have been possible to create one reference datatype which optionally allowed all the different types of identifiers, that method would have resulted in DEMML content documents that were not as easy to read. It would also have allowed invalid combinations of the various identifiers. This method enforces a specific set of combinations of identifiers. It also forces content creators to use the xsi:type= attribute in their reference elements to indicate the actual datatype being used, which allows human readers to easily see what that reference is pointing to. Finally, it allows developers to make use of inheritance and polymorphism, specifying this datatype in an object which then allows all the child datatypes. Points to a spedific Fact-Item within this topic. Points to a specific Fact-Item in a different topic. Points to most types of items within this topic. Note: There is no means to refer to a specific item within a different topic. Used only when an Answer-Item refers to a Question-Item. Indicates if this answer is a correct response to the referred to question. A percentage is used rather than a simply boolean because some answers are worth partial credit. Note: it is not necessary to create a reference from every Answer-Item to every Question-Item indicating the degree of correctness. Instead, only create these references when the answer is a plausible answer to the referred to question or is a good distractor for that question. This way software can automatically create quizes that are different each time. Used only in Explanation-Items to explain why an Answer-Item is or is not a correct answer to a particular question. Because questions and answers can be worded many different ways, while still meaning the same thing, some Explanation-Items may point to more than one question-answer pairs. Used to indicate that this item follows a particular thread. Because a thread could be started anywhere, even in a different topic, this reference must be able to point outside of the topic where it is used.