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)

1. ANY Object Model (COM,CORBA,JAVA,NFS,NAPSTER,SOAP) ...
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

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.

1. Objects inside a given container can be either unordered or ordered. Allowed orderings include

• ASENTERED (order of appearance in XML file)
• SORTEDBY_... (sorting in different ways)
• EXPLICITORDERLIST which specifies ordering by names of objects in a container

2. Ordering defines order of pages in a lecture etc.
3. 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

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

<OBJECTREALIZATIONS>

<OBJECTREALIZATION TYPE=JAVA server=FSUJAVA>

<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

</OBJECTREALIZATION/>

... Repeat for all other realizations

<OBJECTREALIZATIONS/>

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

• COPY name1 -- copies object name1 -- same as symbolic link initially but as can edit object later; the copy and name1 are edited separately
• LINK name2 -- invokes symbolic link to name2 (so components canNOT be changed)
• DELETE name3 -- name3 could be name2/subobject. An example is if name2 was a voice over foil. We can link in original but delete voice subobject
• ADD name4 -- adds local component name4 (could be a new voice-over in previous example)
• CHANGE name5 to name6 -- "roughly" equivalent to DELETE and ADD

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)