A scheme with moxie in Mynx - MOXI XSchema
A Mynx Object XML Interface or MOXI file is an XML file that provides a class interface, but by using XML avoids the specific high-level language dependencies.
The information about a Mynx class that is compiled into a binary, but during the semantic checks for external classes, information about the interface is needed, such as methods, superclasses, attributes, operator overloads. The binary form that is generated is specific, but to avoid compiler dependency on accessing and reading that particular binary form (such as reading the information in a .NET assembly), aneutral markup is used -- a MOXI file. A MOXI file is used to store external semantic information about a Mynx class.
As a MOXI file is XML, its structure and organization can be declared and defined used a schema or XSchema. After pondering and careful consideration, I have created and tested the initial version of the XSchema for a MOXI XML -- moxi.xsd.
The MOXI XSchema uses the “Venetian Blind” approach to structuring the elements and types used in the MOXI file definition. Essentially each major element is organized into its own cluster of elements, with an attribute in the root element indicating the number.
The “Venetian Blind” approach is used for XSchema flexibility and if need be, later to accomodate changes to types and elements ina MOXI file. Each element is a major cluster, and has a corresponding type, and the complex types use simple types for more basic information such as attribute kind or class mode.
A simple MOXI file example with each of the major elements clustered:
The design idea is that when importing the XML MOXI file for a particular class,the information is presented consistently, and locally to each cluster of information. For each cluster of elements that is read, along with the number of them, and the data structure (such as an array) is created containing the information -- but knowing how many elements there are present at first. An empty cluster would have a count of zero, and use an empty tag -- but the count attribute and the root tag is always present-- so consistent, regardless of the information contained in the MOXI file.
A MOXI file is read by a MOXIFileReader into a MOXIObject, both of which are classes in the native implementing high-level language (so optimal for the particular platform Mynx is implemented on) but reading a platform neutral MOXI XML file.
MOXI files can be stored and contained in a ZIP (or other) archive file, or in a directory specifically for them. In Mynx, each file type has a corresponding tool. So a .mynx file has a ‘mynx’ tool -- the compiler. For a MOXI file, there is a corresponding tool ‘moxi.’
The MOXI tool will allow a MOXI file to be read, query for information, and inspect. A visual tool might read in an archive of all the MOXI files contained, and show them in a GUI -- a basic object browser.
A runtime MOXI tool interface can allow for basic reflection and class introspection -- independent of the implementing high-level language. Effectively, the method calls to a reflection library are loading a MOXI file and programatically read, query, and inspect information about the class -- albeit (in a safe form) read-only. But for dynamically querying, and invoking a method is one of the powers of reflection.
The MOXI XSchema is also the (possibly...) basis for the Mynx documentation Myxd XSchema, possibly by extending the XSchema to use comments or annotations. Using XML has the advantage of transformation into HTML, PDF, and other formats from one core document.
Some of the tools I used include Microsoft XML Notepad (very nice) and the XML Schema Inference (way cool -- helped me to think about the XSchema). Others are a schema quality checker tool from IBM, and a validator for an XML document against an XSchema for the Mac (gasp!...yes I have a Mac).
The information about a Mynx class that is compiled into a binary, but during the semantic checks for external classes, information about the interface is needed, such as methods, superclasses, attributes, operator overloads. The binary form that is generated is specific, but to avoid compiler dependency on accessing and reading that particular binary form (such as reading the information in a .NET assembly), aneutral markup is used -- a MOXI file. A MOXI file is used to store external semantic information about a Mynx class.
As a MOXI file is XML, its structure and organization can be declared and defined used a schema or XSchema. After pondering and careful consideration, I have created and tested the initial version of the XSchema for a MOXI XML -- moxi.xsd.
XSchema/MOXI File Design
The MOXI XSchema uses the “Venetian Blind” approach to structuring the elements and types used in the MOXI file definition. Essentially each major element is organized into its own cluster of elements, with an attribute in the root element indicating the number.
The “Venetian Blind” approach is used for XSchema flexibility and if need be, later to accomodate changes to types and elements ina MOXI file. Each element is a major cluster, and has a corresponding type, and the complex types use simple types for more basic information such as attribute kind or class mode.
A simple MOXI file example with each of the major elements clustered:
<?xml version="1.0" encoding="UTF-8"?>
<class supers="0" mode="abstract" module="String" name="String"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<attributes count="1">
<attribute type="String" mode="default" access="public" name="String"
rank="0" kind="constant" isgeneric="true"/>
</attributes>
<constructs count="1">
<construct access="public">
<arg type="String" mode="in" rank="0" isgeneric="true"/>
</construct>
</constructs>
<destructs access="public"/>
<methods count="1">
<method type="String" mode="default" isvoid="true" access="public"
name="doIt" rank="0" isgeneric="false">
<arg type="String" mode="in" rank="0" isgeneric="false"/>
</method>
</methods>
<overloads count="0"/>
<superclasses count="1">
<superclass module="mynx.core" name="Void"/>
</superclasses>
</class>
The design idea is that when importing the XML MOXI file for a particular class,the information is presented consistently, and locally to each cluster of information. For each cluster of elements that is read, along with the number of them, and the data structure (such as an array) is created containing the information -- but knowing how many elements there are present at first. An empty cluster would have a count of zero, and use an empty tag -- but the count attribute and the root tag is always present-- so consistent, regardless of the information contained in the MOXI file.
A MOXI file is read by a MOXIFileReader into a MOXIObject, both of which are classes in the native implementing high-level language (so optimal for the particular platform Mynx is implemented on) but reading a platform neutral MOXI XML file.
MOXI Tool (File => Tool in Mynx)
MOXI files can be stored and contained in a ZIP (or other) archive file, or in a directory specifically for them. In Mynx, each file type has a corresponding tool. So a .mynx file has a ‘mynx’ tool -- the compiler. For a MOXI file, there is a corresponding tool ‘moxi.’
The MOXI tool will allow a MOXI file to be read, query for information, and inspect. A visual tool might read in an archive of all the MOXI files contained, and show them in a GUI -- a basic object browser.
A runtime MOXI tool interface can allow for basic reflection and class introspection -- independent of the implementing high-level language. Effectively, the method calls to a reflection library are loading a MOXI file and programatically read, query, and inspect information about the class -- albeit (in a safe form) read-only. But for dynamically querying, and invoking a method is one of the powers of reflection.
The MOXI XSchema is also the (possibly...) basis for the Mynx documentation Myxd XSchema, possibly by extending the XSchema to use comments or annotations. Using XML has the advantage of transformation into HTML, PDF, and other formats from one core document.
Tools Used to Create XSchema
Some of the tools I used include Microsoft XML Notepad (very nice) and the XML Schema Inference (way cool -- helped me to think about the XSchema). Others are a schema quality checker tool from IBM, and a validator for an XML document against an XSchema for the Mac (gasp!...yes I have a Mac).
Labels: XSchema Mynx MOXI XML
posted by Will Gilreath at
5:02 PM
<< Home