Does Mynx Got MOXI or MOBI -- External Semantics of other Class Types
The first phase of the context semantic checks is complete--the uniqueness check for unit (class or program) elements. The next step is to do the context semantic checks that are specific to a Mynx class or program, and existence check--the TEAC (type existence, annotation, compatibility). The existence is both internal (declared in context or declared before use in a method) and external semantics--the class as a type exists in a external semantic information file.
Mynx compiles into a high-level language (HLL) thus the semantic information needs to be in a form that is independent of platform but is readable into an internal instance object. XML is a natural means to represent the external semantic information of a class. Thus Mynx uses a Mynx Object XML Interface--an XML file that has the semantic information about a class type. Another added bonus with using XML is that it can be transformed, and manipulated with a wide variety of XML tools.
The XML Schema for a MOXI file has been developed, and several test examples to further clarify any design issues. MOXI is the file specification, but later a tool MOXI will allow a visual representation of the MOXI file or files in a Myna (MYNx Archive) file to be browsed and searched. Hence there is the file specification .moxi and a tool Moxi, at least that is the overall intent.
A MOXI file is XML, and the implementation uses a basic XML tokenizer or XMLTokenizer (an open-source project to have XML processing but without the overhead of an XML parser). But in the implementation, a MOXIReader reads the XML file, and creates a MOXIObject -- the runtime instance object containing the semantic information.
The difficulty is that the XML file is very flexible, attributes and tags are required, but in any order, and thus the MOXIReader class must have logic in the processing to handle the flexible order. But it creates complexity, and the goal is to implement the existence context checks. I considered a binary specification and file format--MOBI. The file format is Mynx Object Binary Interface, essentially a MOXI in binary form.
The MOBI specification specifies bytes for the binary information representing semantic information. Of course, a MOBI file cannot take advantage of the plethora of XML tools. A MOBI browser is still possible, but there is also the fact that the binary file is proprietary. A MOBI file offers the efficiency of a binary format, it looses the flexibility and openness of XML. The question or design decision arises of choose MOXI - XML or MOBI - binary.
MOXI is XML with all the benefits and advantages of XML (which some often are vehmently hostile and critical of XML...), and flexibility in the structure--in many ways the XML for a MOXI file is semi-structured. MOBI is rigid and binary, but is efficient but is proprietary binary format.
The compelling reason to use a MOBI file is the rigid format of binary, bytes in specific sequences, and the aversion reason to use a MOXI file is the flexibility. The solution from both perspectives is to force MOXI file to be rigid like binary, only tools or utilities will read the XML file; trade-off in using XML with the excess flexibility makes MOXIReader more complex to handle unpredictability.
A MOXI file requires major elements in alphabetic order, and the attributes within the empty tags to be in alphabetic order. For the major blocks, if empty, use a start-close tag, and use a count attribute to indicate the number of elements.
This is a more strict form of MOXI, it trades-off the XML flexibility, but it goes from semi-structured to structured, and simplifies the implementation of the MOXIReader, and also the MOXIWriter. Later, a more flexible specification is possible, making order immaterial; in which case the stricter earlier version of a MOXI file will be upward compatible with the more flexible.
An example structural fragment of a MOXI file:
Reading and writing a MOXI XML file is needed - the reading is to access external semantic information, and the compiler writes the external class semantic information as the last stage of the compilation process at the end of code synthesis or generation.
However, the implemented functionality is only loading and storing semantic information about a Mynx class. A MOXIObject only represents internally what is externally in a MOXI file.
The last step in designing the external semantics is an interface to query a MOXIObject, to actually access the information. The interface only needs to provide readable access in varying forms such as if a method exists, the type of a method, the mode of an attribute, and so forth. That is the next step in implementing the next stage of semantic checks.
The
A specific check for a method, attribuBlog Does Mynx Got MOXI or MOBI -- External Semantics of other Class Types
February 2008
The first phase of the context semantic checks is complete--the uniqueness check for unit (class or program) elements. The next step is to do the context semantic checks that are specific to a Mynx class or program, and existence check--the TEAC (type existence, annotation, compatibility). The existence is both internal (declared in context or declared before use in a method) and external semantics--the class as a type exists in a external semantic information file.
Mynx compiles into a high-level language (HLL) thus the semantic information needs to be in a form that is independent of platform but is readable into an internal instance object. XML is a natural means to represent the external semantic information of a class. Thus Mynx uses a Mynx Object XML Interface--an XML file that has the semantic information about a class type. Another added bonus with using XML is that it can be transformed, and manipulated with a wide variety of XML tools.
The XML Schema for a MOXI file has been developed, and several test examples to further clarify any design issues. MOXI is the file specification, but later a tool MOXI will allow a visual representation of the MOXI file or files in a Myna (MYNx Archive) file to be browsed and searched. Hence there is the file specification .moxi and a tool Moxi, at least that is the overall intent.
A MOXI file is XML, and the implementation uses a basic XML tokenizer or XMLTokenizer (an open-source project to have XML processing but without the overhead of an XML parser). But in the implementation, a MOXIReader reads the XML file, and creates a MOXIObject -- the runtime instance object containing the semantic information.
The difficulty is that the XML file is very flexible, attributes and tags are required, but in any order, and thus the MOXIReader class must have logic in the processing to handle the flexible order. But it creates complexity, and the goal is to implement the existence context checks. I considered a binary specification and file format--MOBI. The file format is Mynx Object Binary Interface, essentially a MOXI in binary form.
The MOBI specification specifies bytes for the binary information representing semantic information. Of course, a MOBI file cannot take advantage of the plethora of XML tools. A MOBI browser is still possible, but there is also the fact that the binary file is proprietary. A MOBI file offers the efficiency of a binary format, it looses the flexibility and openness of XML. The question or design decision arises of choose MOXI - XML or MOBI - binary.
MOXI is XML with all the benefits and advantages of XML (which some often are vehmently hostile and critical of XML...), and flexibility in the structure--in many ways the XML for a MOXI file is semi-structured. MOBI is rigid and binary, but is efficient but is proprietary binary format.
The compelling reason to use a MOBI file is the rigid format of binary, bytes in specific sequences, and the aversion reason to use a MOXI file is the flexibility. The solution from both perspectives is to force MOXI file to be rigid like binary, only tools or utilities will read the XML file; trade-off in using XML with the excess flexibility makes MOXIReader more complex to handle unpredictability.
A MOXI file requires major elements in alphabetic order, and the attributes within the empty tags to be in alphabetic order. For the major blocks, if empty, use a start-close tag, and use a count attribute to indicate the number of elements.
This is a more strict form of MOXI, it trades-off the XML flexibility, but it goes from semi-structured to structured, and simplifies the implementation of the MOXIReader, and also the MOXIWriter. Later, a more flexible specification is possible, making order immaterial; in which case the stricter earlier version of a MOXI file will be upward compatible with the more flexible.
An example structural fragment of a MOXI file:
Reading and writing a MOXI XML file is needed - the reading is to access external semantic information, and the compiler writes the external class semantic information as the last stage of the compilation process at the end of code synthesis or generation.
However, the implemented functionality is only loading and storing semantic information about a Mynx class. A MOXIObject only represents internally what is externally in a MOXI file.
The last step in designing the external semantics is an interface to query a MOXIObject, to actually access the information. The interface only needs to provide readable access in varying forms such as if a method exists, the type of a method, the mode of an attribute, and so forth. That is the next step in implementing the next stage of semantic checks.
The
A specific check for a method, attribute, or operator is next, driven by the need to do it as part of the Mynx compiler.
MOXI Concept
Mynx compiles into a high-level language (HLL) thus the semantic information needs to be in a form that is independent of platform but is readable into an internal instance object. XML is a natural means to represent the external semantic information of a class. Thus Mynx uses a Mynx Object XML Interface--an XML file that has the semantic information about a class type. Another added bonus with using XML is that it can be transformed, and manipulated with a wide variety of XML tools.
The XML Schema for a MOXI file has been developed, and several test examples to further clarify any design issues. MOXI is the file specification, but later a tool MOXI will allow a visual representation of the MOXI file or files in a Myna (MYNx Archive) file to be browsed and searched. Hence there is the file specification .moxi and a tool Moxi, at least that is the overall intent.
MOXI Implementation
A MOXI file is XML, and the implementation uses a basic XML tokenizer or XMLTokenizer (an open-source project to have XML processing but without the overhead of an XML parser). But in the implementation, a MOXIReader reads the XML file, and creates a MOXIObject -- the runtime instance object containing the semantic information.
The difficulty is that the XML file is very flexible, attributes and tags are required, but in any order, and thus the MOXIReader class must have logic in the processing to handle the flexible order. But it creates complexity, and the goal is to implement the existence context checks. I considered a binary specification and file format--MOBI. The file format is Mynx Object Binary Interface, essentially a MOXI in binary form.
MOBI File
The MOBI specification specifies bytes for the binary information representing semantic information. Of course, a MOBI file cannot take advantage of the plethora of XML tools. A MOBI browser is still possible, but there is also the fact that the binary file is proprietary. A MOBI file offers the efficiency of a binary format, it looses the flexibility and openness of XML. The question or design decision arises of choose MOXI - XML or MOBI - binary.
MOXI is XML with all the benefits and advantages of XML (which some often are vehmently hostile and critical of XML...), and flexibility in the structure--in many ways the XML for a MOXI file is semi-structured. MOBI is rigid and binary, but is efficient but is proprietary binary format.
The compelling reason to use a MOBI file is the rigid format of binary, bytes in specific sequences, and the aversion reason to use a MOXI file is the flexibility. The solution from both perspectives is to force MOXI file to be rigid like binary, only tools or utilities will read the XML file; trade-off in using XML with the excess flexibility makes MOXIReader more complex to handle unpredictability.
MOXI Requirements
A MOXI file requires major elements in alphabetic order, and the attributes within the empty tags to be in alphabetic order. For the major blocks, if empty, use a start-close tag, and use a count attribute to indicate the number of elements.
- Attributes within a tag in alphabetic order.
- Major element blocks in alphabetic order within CLASS block.
- Major blocks always use start/close tags with count attribute--even when empty.
- Default and destruct are empty tag.
- outer block is a MOXI block, inner block is CLASS block.
This is a more strict form of MOXI, it trades-off the XML flexibility, but it goes from semi-structured to structured, and simplifies the implementation of the MOXIReader, and also the MOXIWriter. Later, a more flexible specification is possible, making order immaterial; in which case the stricter earlier version of a MOXI file will be upward compatible with the more flexible.
An example structural fragment of a MOXI file:
<moxi version=''>
<class mode='' module='' name=''>
<attributes count=''>
<attribute ... />
</attributes>
<constructs count=''>
<construct ... >
<args ... >
<arg ... />
</args>
</construct>
</constructs>
<default />
<destruct />
<methods count=''>
<method ... >
<args ... >
<arg ... />
</args>
</method>
</methods>
<overloads count=''>
<overload ... />
</overloads>
<superclasses count=''>
<superclass .../>
</superclasses>
</class>
</moxi>
MOXI Query for Semantics
Reading and writing a MOXI XML file is needed - the reading is to access external semantic information, and the compiler writes the external class semantic information as the last stage of the compilation process at the end of code synthesis or generation.
However, the implemented functionality is only loading and storing semantic information about a Mynx class. A MOXIObject only represents internally what is externally in a MOXI file.
The last step in designing the external semantics is an interface to query a MOXIObject, to actually access the information. The interface only needs to provide readable access in varying forms such as if a method exists, the type of a method, the mode of an attribute, and so forth. That is the next step in implementing the next stage of semantic checks.
The
IQueryMOXI interface and the underlying MOXIObject implementation. For now, the types are checked for external existence from internal existence in a declaration. A specific check for a method, attribuBlog Does Mynx Got MOXI or MOBI -- External Semantics of other Class Types
February 2008
The first phase of the context semantic checks is complete--the uniqueness check for unit (class or program) elements. The next step is to do the context semantic checks that are specific to a Mynx class or program, and existence check--the TEAC (type existence, annotation, compatibility). The existence is both internal (declared in context or declared before use in a method) and external semantics--the class as a type exists in a external semantic information file.
MOXI Concept
Mynx compiles into a high-level language (HLL) thus the semantic information needs to be in a form that is independent of platform but is readable into an internal instance object. XML is a natural means to represent the external semantic information of a class. Thus Mynx uses a Mynx Object XML Interface--an XML file that has the semantic information about a class type. Another added bonus with using XML is that it can be transformed, and manipulated with a wide variety of XML tools.
The XML Schema for a MOXI file has been developed, and several test examples to further clarify any design issues. MOXI is the file specification, but later a tool MOXI will allow a visual representation of the MOXI file or files in a Myna (MYNx Archive) file to be browsed and searched. Hence there is the file specification .moxi and a tool Moxi, at least that is the overall intent.
MOXI Implementation
A MOXI file is XML, and the implementation uses a basic XML tokenizer or XMLTokenizer (an open-source project to have XML processing but without the overhead of an XML parser). But in the implementation, a MOXIReader reads the XML file, and creates a MOXIObject -- the runtime instance object containing the semantic information.
The difficulty is that the XML file is very flexible, attributes and tags are required, but in any order, and thus the MOXIReader class must have logic in the processing to handle the flexible order. But it creates complexity, and the goal is to implement the existence context checks. I considered a binary specification and file format--MOBI. The file format is Mynx Object Binary Interface, essentially a MOXI in binary form.
MOBI File
The MOBI specification specifies bytes for the binary information representing semantic information. Of course, a MOBI file cannot take advantage of the plethora of XML tools. A MOBI browser is still possible, but there is also the fact that the binary file is proprietary. A MOBI file offers the efficiency of a binary format, it looses the flexibility and openness of XML. The question or design decision arises of choose MOXI - XML or MOBI - binary.
MOXI is XML with all the benefits and advantages of XML (which some often are vehmently hostile and critical of XML...), and flexibility in the structure--in many ways the XML for a MOXI file is semi-structured. MOBI is rigid and binary, but is efficient but is proprietary binary format.
The compelling reason to use a MOBI file is the rigid format of binary, bytes in specific sequences, and the aversion reason to use a MOXI file is the flexibility. The solution from both perspectives is to force MOXI file to be rigid like binary, only tools or utilities will read the XML file; trade-off in using XML with the excess flexibility makes MOXIReader more complex to handle unpredictability.
MOXI Requirements
A MOXI file requires major elements in alphabetic order, and the attributes within the empty tags to be in alphabetic order. For the major blocks, if empty, use a start-close tag, and use a count attribute to indicate the number of elements.
- Attributes within a tag in alphabetic order.
- Major element blocks in alphabetic order within CLASS block.
- Major blocks always use start/close tags with count attribute--even when empty.
- Default and destruct are empty tag.
- outer block is a MOXI block, inner block is CLASS block.
This is a more strict form of MOXI, it trades-off the XML flexibility, but it goes from semi-structured to structured, and simplifies the implementation of the MOXIReader, and also the MOXIWriter. Later, a more flexible specification is possible, making order immaterial; in which case the stricter earlier version of a MOXI file will be upward compatible with the more flexible.
An example structural fragment of a MOXI file:
<moxi version=''>
<class mode='' module='' name=''>
<attributes count=''>
<attribute ... />
</attributes>
<constructs count=''>
<construct ... >
<args ... >
<arg ... />
</args>
</construct>
</constructs>
<default />
<destruct />
<methods count=''>
<method ... >
<args ... >
<arg ... />
</args>
</method>
</methods>
<overloads count=''>
<overload ... />
</overloads>
<superclasses count=''>
<superclass .../>
</superclasses>
</class>
</moxi>
MOXI Query for Semantics
Reading and writing a MOXI XML file is needed - the reading is to access external semantic information, and the compiler writes the external class semantic information as the last stage of the compilation process at the end of code synthesis or generation.
However, the implemented functionality is only loading and storing semantic information about a Mynx class. A MOXIObject only represents internally what is externally in a MOXI file.
The last step in designing the external semantics is an interface to query a MOXIObject, to actually access the information. The interface only needs to provide readable access in varying forms such as if a method exists, the type of a method, the mode of an attribute, and so forth. That is the next step in implementing the next stage of semantic checks.
The
IQueryMOXI interface and the underlying MOXIObject implementation. For now, the types are checked for external existence from internal existence in a declaration. A specific check for a method, attribute, or operator is next, driven by the need to do it as part of the Mynx compiler.
Labels: context semantic, existence semantics, MOBI, Mynx MOXI XSchema, type semantics
posted by Will Gilreath at
12:51 AM
<< Home