o2xdl    Reference

General

The objectives pursued in the o2xdl project are:
  • o2xdl is an OO language entirely defined and implemented in XML.
  • o2xdl MUST be strictly OO.
  • o2xdl MUST allow the modeling of complex data structures and their transformations.
  • o2xdl MUST use only XSLT transformations as processing language.
  • o2xdl objects MUST be self-sufficient and modifiable at runtime.
  • o2xdl MUST be clear: in the definitions and implementations there MUST NOT be any constraints that are not essential.
  • o2xdl MUST use updated standards.
  • o2xdl applications MUST be easily modeled in UML, with standard programs.
  • implementations of development and production environments for o2xdl MUST be compatible with both local and distributed deployement.
Persistence and identity
The persistence of Classes and Objects, together with their identity, are the keystone for the major features of o2xdl: inheritance, modularization, reuse, dynamic composition at run-time.
Orthogonal composition
We want to have objects "composed" of other objects. The object composition operation must be orthogonal and implement the typical data structures (set, tree, tuple, list...).
Formal correctness
o2xdl must completely define a strict OO model, and allow a natural use of the UML for the phases of Analysis and Project.
Limited constraints
o2xdl must be little "demanding", do not place a priori constraints on the type of DATA used (e.g. DTD or pre-existing scheme), be totally portable and "transparent" with respect to the environment and XML host technology.
Implementation elasticity
Formal correctness and limited constraints must lead to great strategic and implementation freedom, for optimization in all scenarios.
Expressive power
The use of XSLT as a processing language should not be seen as a limitation.
In fact, it has been demonstrated how it is possible to use XSLT as a complete functional language (see http://fxsl.sourceforge.net ).>br /> More, the XSLT is a "Turing complete" language (see http://www.unidex.com/turing/utm.htm ) ie able to implement any Turing machine.
Fields of application
o2xdl is General Purpose: it can be applied for the use of information or for the realization of projects starting from the descriptive data in all cases where:
  • The starting data are in XML format (data entered by the user, existing DBs etc ...)
  • The requested result can be obtained with XSLT transformations (XHTML pages, HTA programs, pdf texts, SVG and VRL graphics, Flash animations (SWF), etc ...)...)
  • It makes sense to organize either the data or the result in hierarchies of objects....)

CORE level







The o2xdl - CORE level - is a complete laguage for objects, which uses trees of o2x:objects to represent complex data structures and perform transformations on them. CORE is independent of the technology used to create the o2x:objects.

o2x:object

Each o2x:object must be 'realizable', i.e. it MUST contains all the required data and methods. 
	<o2x:object
		name="string [0..1] "
		key="NMTOKEN [0..1] "
		target="string [0..1] "
		position="NMTOKEN [0..1] "
		actualContext="NMTOKEN [0..1] "
		URIref="anyURI [0..1] "
		Allow any attributes from any namespace (lax validation).
		> 
		Allow any elements from a namespace other than this schema's namespace (lax validation). [0..*]
		Start Choice [0..*]
			<o2x:dataValues> o2x:ReferenceType </o2x:dataValues> [1] 
			<o2x:method> ... </o2x:method> [1] 
			<o2x:contentList> ... </o2x:contentList> [1] 
			<o2x:annotation> ... </o2x:annotation> [1]
		End Choice
	</o2x:object>
  • In CORE the name attribute is optional.
  • The key attribute is reserved for internal use.
  • The target attribute CAN define the final destination file.
  • The position attribute CAN be used to identify an o2x:object when it is in an o2x:contentList.
  • The actualContext attribute CAN forces the context used by Realize() with the o2x:object.
  • The URIref attribute CAN reference a local or remote implementation. In this case the o2x:object can be empty.

o2x:dataValues

The o2x:dataValues element contains the XML data to be transformed. 
	<o2x:dataValues
		name="string [0..1]"
		URIref="anyURI [0..1]"
		Allow any attributes from any namespace (lax validation).
		> 
		Start Choice [0..*]
			<o2x:body> o2x:XMLtree </o2x:body> [1]
			<o2x:annotation> ... </o2x:annotation> [1]
		End Choice
	</o2x:dataValues>
An o2x:object can contain zero, one or more elements o2x:dataValues. The XML data of an o2x:dataValues node can be defined:

By-value, i.e. being contained in the child element o2x:body
  • as the only text node (CDATA section)
  • as an XML tree
By-reference, i.e. being contained in an external file, referenced by the attribute URIref
  • Local absolute URI
  • Remote absolute URI
notes
  • In CORE the name attribute is optional
  • In the case of the simultaneous presence of the URIref attribute and the o2x:body element Realize() gives precedence to inline data.
  • If the data is contained in an external file, this must be a valid XML file, so the data must form a tree with a single root element.
    Even if this constraint falls when the data is contained in the o2x:body element, it is always appropriate to use a valid XML tree for the data.
  • If there are multiple o2x:dataValues, these are merged by Realize()
  • To maximize compatibility with existing situations, CORE does not place any other constraints on the content of o2x:dataValues.
  • The use of namespaces is recommended but optional in the XML tree contained in o2x:dataValues.

o2x:method

In an o2x:object each o2x:method element is responsible of the access or transformation of the o2x: dataValues present. 
	<o2x:method
		name="string [0..1]"
		key="NMTOKEN [1]"
		context="NMTOKEN [0..1]"
		URIref="anyURI [0..1]"
		visibility="string (value comes from list: {'final'|'protected'|'public'|'private'|'virtual'|'static'}) [0..1]"
		Allow any attributes from any namespace (lax validation).
		> 
		Start Choice [0..*]
			<o2x:paramValues> o2x:ReferenceType </o2x:paramValues> [1]
			<o2x:inline> o2x:XMLtree </o2x:inline> [1]
			<o2x:annotation> ... </o2x:annotation> [1]
		End Choice
	</o2x:method>
The o2x:method element is implemented via standard XSLT transformations.
An o2x:object can have zero, one or more o2x:methods, but to be realizable MUST have at least one o2x:method.
An o2x:method can be defined
By-value, i.e. being contained in the child element o2x:inline
  • as the only text node (CDATA section)
  • as an XML tree
By-reference, i.e. to be contained in an external file, referenced by the attribute URIref
  • Local absolute URI
  • Remote absolute URI
notes
  • In CORE the name attribute is optional.
  • The key attribute is mandatory and must be globally unique.
  • To make the o2x:method more flexible, any method CAN have one or plus <o2x:paramValues>, element like o2x:dataValues, but method's private.
    At runtime, the data in o2x:paramValues become child of the o2x:object element, like all o2x:dataValues contents: make sure the root tags are differents to avoid conflicts.
  • The same o2x:paramValues can be shared between many objects or between different methods if it is defined 'by_refence'.
  • An o2x:method CAN be classified using the optional attribute context. This attribute allows to choose between many methods the unique method used by Realize() at runtime.
  • An o2x:method CAN be classified also using the optional attribute visibility, which allows the presence of more methods.
    visibility="final"
    Identifies an o2x:method that can be used for the realization of an o2x:object, i.e. that is responsible for the transformation of all the elements in o2x:dataValues.
    This is the unique value of visibility used by CORE.
    visibility="public"|"protected"|"private"|"virtual"|"static"
    At CORE level this values are hints for the programmer.
  • For every context value there MUST be no more than one "final" method
visibility and context
At runtime, Realize() uses the values "runtime_context" and visibility to choose one main method. Rules:
  1. The unique o2x:method having (@visibility="final" and @context="runtime_context"), if any, or
  2. The unique o2x:method having (@visibility="final" and (not @context)), if any, or
  3. The unique o2x:method having ((not @visibility) and @context="runtime_context"), if any, or
  4. The unique o2x:method having ((not @visibility) and (not @context))
  5. All o2x:method having (@context != "runtime_context") are ignored.
The value of "runtime_context" is defined for any o2x:object by following rules:
  1. The value in the o2x:object/@actualContext attribute, if it exists and if it is not equal to "none", else
  2. The parent's "runtime_context", if this o2x:object is in an o2x:contentList, else
  3. The value defined at runtime, by Realize() , if it is not equal to "none", else
  4. The default value defined in the o2xdl environment, in the file ...\CORE\o2xdl-system.xml
final binding
The automatic application of the 'main method' to the data of the same object ​​is performed by Realize() and this requires a special template binding technique, which we call "final binding". 
		<xsl:template match = "o2x:object[@key = '«method_key»']/«data_root» ">
		.....
		</xsl:template>
	alternative:
		<xsl:template match = "o2x:object[@key = '« method_key »']">
			<xsl:apply-templates select = "«data_root»" mode = "«method_key»" />
		</xsl:template>
  • The evocation of the main o2x:method to realize an object is implicit and automatic.
  • If instead it must be explicitly inserted into the implementation of another method (e.g. in the case of complex objects), just use <xsl: apply-templates> selecting the o2x: object to be realized. For example:  
    <xsl:apply-templates select="o2x:contentList/o2x:object" />
  • A "final" template can not be used with <parameter> element.
modal binding
If multiple xsl:templates are required to implement an o2x:method, all this templates MUST be uniquely identified, using "mode=«method_key»" attribute, or modified, e.g. "mode=«method_key».pass1": 
	<xsl:template   match="«any_data»"   mode="«method_key»">
	.....
	</xsl:template>
hearly binding
 An o2x:method with a visibility different from "final" has as its objective or the realization of specific elaborations or the implementation of a correct "data hiding" according to the OO canons, and can be implemented and used according to two different bindig strategies.
In the case of "hearly binding" (static binding):
  • The xsl:template to be used is defined once and for all in the code that calls it.
  • The xsl:template can be applied to any node of DataValues, regardless of the name.
  • The node to which the xsl:template should be applied must be the current node.
  • Its use must be via <xsl:call-template>
  • The o2x:method is implemented through a "named template"
	<xsl:template name = "«method_key»">
	.....
	</xsl:template>
late binding
  • The xsl:template to be used is defined at runtime, depending on the object to which it is applied (polymorphism).
  • Its use must be via <xsl:apply-templates>
  • The o2x:method is implemented through a standard template:
	<xsl:template match="«data_root»" mode = "«group_id»">
	.....
	</xsl:template>
	... more templates, with mode=«group_id».«data_root»
  • The «group_id» is common to many o2x:methods semantically equivalent but in different objects (it is the 'name' of the polymorphic method).
  • Any xsl:template applies to a specific node of DataValues, so "data_root" must be unique at the "group_id" level.
  • The selection of more templates (modal binding) is then defined with the composite key: "group_id"+"data_root".

o2x:contentList

The list of o2x:objects included in an o2x:object 
	<o2x:contentList
		name="string [0..1] ?"
		Allow any attributes from any namespace (lax validation).
		> 
		Start Choice [1..*] 
			<o2x:object> ... </o2x:object> [1] 
			<o2x:annotation> ... </o2x:annotation> [1]
		End Choice
	</o2x:contentList><pre>
  • The name attribute can be used to select between many lists.
  • The <o2x:object>/@position attribute can be used to select between many o2x:objects in a contentList to implement the typical data structures (set, bag, tuple, list, tree....)
  • The simplest way to realize the elements in a o2x:contentList is:
    <xsl:apply-templates select="o2x:contentList[@name=’xxx’]/>
  • If all the 'final' o2x:methods contain this code fragment (or equivalent), each object can be aggregated using any other object, achieving the complete orthogonality.

o2x:annotation

This element is allowed in almost any place. 
	<o2x:annotation> 
		Start Choice [1..*]
			<o2x:appinfo> ... </o2x:appinfo> [1]
			<o2x:documentation> ... </o2x:documentation> [1]
		End Choice
	</o2x:annotation>
  • The appinfo is for automatic processing.
  • The documentation is for human readers.
Details: 
	<o2x:appinfo
		source="anyURI [0..1] ?"
		> 
		<!-- Mixed content -->
		Start Sequence [0..*]
			Allow any elements from any namespace (lax validation). [1]
		End Sequence
	</o2x:appinfo>
			
	<o2x:documentation
		source="anyURI [0..1] ?"
		xml:lang="[0..1]"> 
		<!-- Mixed content -->
		Start Sequence [0..*]
			Allow any elements from any namespace (lax validation). [1]
		End Sequence
	</o2x:documentation>
  • source allows the inclusion of references.
  • xml:lang for internalization.