GXOS: General Purpose (Garnet) XML Object Specification

This is to be designed to support initially

  1. Education/Training where it will be compatible with IMS/ADL SCORM in sense that IMS/SCORM compatible specifications can be generated from GXOS objects but GXOS will be more powerful than IMS/SCORM
    IMS is http://www.imsproject.org
    ADL/SCORM is http://www.adlnet.org
  2. Computing where we need to be mindful of Grid Forum and Gateway
  3. General Web sites
  4. As a hierarchical set of containers it should be compatible with SCORM for large containers (lectures) and W3C DOM for small objects (document fragments)

In my terminology one should support resourceML and portalML corresponding to XML at different parts of system (different XML parsers on different servers)


  2. Objects will be managed like files in a UNIX/windows system
    i.e. hierarchical organization and symbolic links
    search either by hierarchy or by "search for file names/file contents" with various criteria on object type etc.
  3. Typically one will interact with the XML metadata about object rather than object itself
  4. Objects will be labeled liked files with either relative or absolute names with a hierarchial structure. The container (logical arrangement of objects) structure can have a different hierarchical structure from naming
  5. We discuss here general object properties. GXOS objects will have other properties such as objectives, prerequisites for SCORM objects and W3C DOM properties for objects of Web Page or smaller size. A given object can inherit such specialized properties from multiple sources. Tags can use attribute TAGSOURCE = GXOS, W3DOM, SCORM to indicate their source. A MAPPINGOBJECT tag will tell you how to map into a particular TAGSOURCE. You could for example here specify that a particular container was either a BLOCK or AU in SCORM
  6. Everything is a GXOS object -- including not only curriculum pages but audio/video archives, background images/buttons/menus for building web-pages etc. Normally you store the different object types in separate container hierarchies cross-referencing through NAME attribute

XML Object Specification

  1. All Objects are Containers (i.e. in file analogy directories) i.e All Objects can be constructed from any number (including zero) other objects
  2. An object can be an ALIAS to another object. ALIAS acts as a "symbolic link" so that when object link points to changes, then ALIASed object changes
  3. An object can be defined by a BUILTUP tag, which defines how one constructs this object from other objects either inside or outside this container.
  4. All objects have names, which are generated automatically in some natural fashion if not explicitly given
  5. Objects can be defined in terms of subobjects which have roles such as Documentfragment, backgroundimage etc. One can use an index (any character string) to differentiate more than one object with the same role. These roles are used in templates or layout in portalML
  6. Objects can have multiple INSTANTIATIONS, which can specify how to use your favorite object model to access object. An example is given below. The realizations may not be identical as some object models may implement a given object more or less well You can use a pure Java EJB system to manage your objects as long as it interprets OBJECTREALIZATION to access an object stored in CORBA or some other (than pure Java model
  7. Objects can have one or more OBJECTRENDERINGs defined. These are differentiated by use (thumbnail is different from normalview) or rendering device
  8. Objects can have RANKS's assigned. The use is application dependent but in education it is used to identify objects of the same type which should therefore be treated in a given way. RANK = CurriculumPage is typical unit of instruction and all objects of this rank in a given container form a natural linked list. Other values for rank could be RANK= PageFragment, Lecture, Module1, Module2, Course, Program ...
  9. CONTAINERRANK specifies the RANK of "important" subobjects stored in this object (container). For example, a container could have RANK=Lecture and CONTAINERRANK = CurriculumPage
  10. An object can have tag <CONTAINERABSTRACT/> to indicate that it specifies abstract of container in which it is placed. For example in my PowerPoint presentations, I typically put abstract as second slide.
  11. An object can have a TABLEOFCONTENTS tag specifying how Table of Contents is to be generated. Often this is gotten from accessing TITLE tag of all contained objects with RANK=CONTAINERRANK. One could also specify (in a syntax to be decided) how to generate more complete tables of contents.
  12. We will use IMS/IEEE LTSC metadata which has tags to specify Title, Author etc. for GXOS objects. Maybe we could simplify this to Dublin Core or other simpler metadata for non educational objects. This tag set contains keywords etc.
  13. METADATAHEURISTICS tag can be used to guide object manager into quick ways of building Metadata inside its container. This could for example specify that Author and Title for subobjects gotten from PowerPoint be generated from PowerPoint properties and slide Title
  14. EVENTLIST is the list of events associated with this object desribing its use and changes to it.


XML Container Structure

  1. Objects inside a given container can be either unordered or ordered. Allowed orderings include
  1. Ordering defines order of pages in a lecture etc.
  2. Objects can be defined either by a list of components with a mapping of subobject names to role[index] where rendering algorithm will use some sort of template to insert each role[index] into a given web page Alternatively, one can specify container as an XML file where this file references role[index] objects in an <ANYOLDTAG TAGSOURCE=GXOS attributename=GXOS//:role[index] like syntax. The GXOS Object Manager will replace role[index] with "real object" reference

Typical Object Instantiation specification for Computing Object --------------------------

(these are more likely to have important methods than educational objects)



<OBJECTSERVER LOCATION="birch.csit.fsu.edu:8200" />

<OBJECTPOSITION ADDRESS="wherejavaobjectstoredonserver" />

<PARAMETER NATIVE=Iteration OBJECTVIEW="Num_Iterations" /> maps parameter name used in parameter specification in XML to name in object land. NATIVE values would be described in basic XML of object. There is one set of NATIVE characteristics intrinsic to object Each Realization could access with arecane names or not be able to access perhaps

<PARAMETER NATIVE=bondlength status=NA />

<EVENT NATIVE=ENDOFJOB objectview="End_Job" /> map events

<EVENT NATIVE=ENDOFITERATION STATUS=NA /> NA implies this event/parameter not available in this realization


... Repeat for all other realizations


BUILTUP Structure ----------------------------------------------------------------------

1) This allows you to define new objects from old ones as a set of actions to be executed in order

2) Allowed actions include

Object Rendering ------------------------------------------------------------------------

  1. Any number of renderings are allowed
  2. They have a USE (default, thumbnail, normalview) and a DISPLAYDEVICE (Palm, PC, Cave) and someway of essentially specifying display template with DISPLAYTYPE = VirtualClassroom, MyProfessor, Plainoldwebpage etc.
  3. The rendering can specify the server which is to perform rendering e.g. to convert XML into HTML or WML (Renderer=backend or userportal)
  4. The rendering uses portalML
  5. Here you can specify displays of different resolution, text only version, and universal access (for example for visually impaired)