Exploring the basic principles of Microxml

Microxml is one of the results of these discussions. Microxml is a backward-compatible, simplified version of XML, where the prominence of some of the participants and the timing of the microxml appear. John Cowan has developed the Microxml parser in Java™ and other related tools. This article describes the technical differences between Microxml and its XML 1.x and related standards.

XML is a highly successful technology, but it is not without flaws. After great success, there are always some critical scrutiny, and many people try to redesign XML from the beginning. People use the latest XML processing specifications, such as XPath, XSLT, and XQuery 3.0, to address the complexities of XML namespaces. Some of the most influential core XML experts have also ventured to explore the possibility of implementing a simplified version of XML from the beginning.

Another factor contributing to this situation is the threat posed by http://www.aliyun.com/zixun/aggregation/79228.html > HTML5 Web Browser developers. Sometimes called XHTML5, a technology that fundamentally subverts XML violates some of the most important principles of XML ecosystems. However, most HTML5 users think XHTML5 is far less convenient than HTML5.

This combination of forces has sparked intense debate in the Xml-dev mailing list and various blogs. In the end, James Clark released the full proposal of Microxml. John Cowan, who works in the XML Core workgroup of the consortium, became the main contributor and editor of this specification.

Microxml does not represent the official position of any recognized standards organization, but for a variety of reasons, this specification is extremely appealing to XML developers. John Cowan developed its Java implementation Microlark, and I developed a Python implementation. People are enthusiastic about microxml norms. Remember that many of the most important modern norms (such as JSON and markdown) have similar unofficial origins.

One of the most valuable aspects of understanding microxml is that it helps you understand the most effective way to implement pure XML. In this article, you will learn about Microxml. The example in this article explores the key differences between Microxml and pure XML. In addition, the basic principles will be elaborated. This article assumes that you are familiar with the basics of XML.

Microxml guidelines

The two key objectives of Microxml are:

maintains a very simple data model to maintain backward compatibility with XML

All other aspects derive from these two objectives. Microxml documents are well-formed XML documents. Microxml is also designed to be friendly and compatible with HTML5 and JSON.

The specification of the XML data Model Infoset and XPath data Model (XDM) is up to dozens of pages long. Even the specification of the XPath 1.0 data Model, which is highly acclaimed for elegance and lightness, has several pages. If you do not consider the JSON compatibility Note, the specification for the Microxml data model is only half a page. John Cowan even condensed all of his content into the following passage.

the data model for a document contains at least one element object. An element object is an abstract description of a single element in a document. Each element object has three related attributes: Name, property map, and child object sequence. The name is a string that maps the name string to a value string, and each child object in the sequence is a string or element object that represents the character data. ”

The following sections of this article will focus on the microxml syntax, which comes directly from the data model. The encapsulation concept in Microxml is documentation, which is the result of parsing an input stream that conforms fully to the Microxml specification.

Good format

The most fundamental difference between XML and Microxml is the way the parser behaves. The error handling of XML is notorious for its carping, and when using XML error handling, the parser must abort immediately when the first error occurs. This approach is highly controversial, especially given that HTML has made people accustomed to rough tags. XML critics also cite Bostalfa: Conservative send, open reception.

In Microxml, the parser can continue to run even if an error occurs. However, at the point where the error occurred, the input must be marked as not archived, allowing the compliant Microxml parser to switch to different input interpretations. Just think about how the HTML parser switches from the standard mode to the "tag soup" mode, and you can understand this concept.

For example, suppose an XML processor encounters the following input, you must stop immediately when you reach </para>, which raises a bad format error about mismatched end tags.

&lt;para&gt;hello, I claim to be &lt;strong&gt;MicroXML&lt;/para&gt;

In the same case, the Microxml parser can continue to operate, but will not report input as a microxml document. It can even fix the output, insert a </strong> before </para>, but also cannot declare that the result belongs to the Microxml document. If you are designing a real system that must handle unpredictable input, the subtle easing of the formatting constraints can make a huge difference.