Http://www-900.ibm.com/developerWorks/cn/xml/x-sysyntax/index.shtml
Very good article! It involves the problem I have always considered, how to simplify the editing of XML (it clearly points out a root of the difficulty I haven't realized XML editing: the most commercial XML editor also needs to be positioned and click to a certain extent, This has become a blocking role that is fast and free.
Like Wiki, a more concise hypertext language is also the starting point for my early Naxt project trial. In fact, in the medium term, I am aware that even if I am very rigorous, I have a consistent characteristic collection and grammar, it is necessary to make more clear definitions of application. Therefore, I now tend to define Naxt as an equivalent compact grammore of XHTML2 (or its subset). This avoids excessive entanglement of semantics.
In the attempt of the NAXT project, I gradually turned to the general-purpose TXT2XML literary law parser and converter. BTW, while the other line I am paying attention to the simple text format of the specific area is the universal expression of the specific XML editor (rather than writing a special editor for each dialect), For example, I have a great expectation to define XForms as a generalized XML editing interface.
Continue, mentioning many of the designs (such as very successful Relax Ng and its Compact syntax), especially XSLTXT. In fact, from the first time I came into contact with RESIN, I also consider the compact replica of XSLT for a long time. This way I have the following: XSLT itself, xslt-lite (stylescript), xsltxt, xquery, jxpath, gpath. Of course, I also have a major problem with design. It is not considered. Is it a direct XSLT corresponding or more close to an independent template language (such as allowing to destroy Well-Formed, or even beyond declarative allowed side effects)? Despite the agility language of Groovy's general and convenience, I think there is still necessary to consider the XSLT program, because it is standard, platform neutral, widely accepted, with maximum interoperability (therefore need to be carefully dealt with side effects) Such an extension), and has a unique and powerful "template automatic application". General template technology does not have this abstract mechanism.
The conclusion of the article puts forward some important issues, which is what I have realized or unrecognizable.
... The shortcomings of the compressed syntax are the test of interoperability and whether it can be accommodated. Most results come from a separate third party. It is not fully clear to what supports for thousands of character codes and those that are rarely used XML components (such as processing instructions). In addition, in most cases, they only exist of a founder, so their idea is likely to gradually die.
... Don't ignore the interoperability of XML 1.0 and its impact on the network. These are the main value of XML, but also the main reason for us to go today.
... In addition to the general XML alternative grammar, the application-specific non-XML syntax seems to have more value, especially those that need to create a large amount of content. ... but there is a reasonable trade-off in terms of easy editing. Relax Ng Compact is a good example, which means that non-XML syntax does reveal the underlying concept and data structure of the language ...
Easy to create content is still the most intense debate I have ever seen in the use of alternative XML. The editor development seems to be one of the most difficult problems in the calculation, and rarely finds help.
After reading and thinking, I should still rewrite a general TXT2XML tool. However, it is necessary to define a language that represents a textual literary law. I have considered many similar tools, especially those such as XI and other Rules, but now I speculate maybe I can use RNG to some extent? The road is still very ...
