A further core component of onion.net is schema-based information architecture.
What does that mean? Basically just that all data sources connected to an onion.net system are standardised as XML. It is therefore of no concern to the developer where the information comes from (onion.net, SQL data base, web resource…), since they can all be treated in the same way and are all available in onion.net in XML.
In order to establish a “common grammar” as it were, the XML document types are described in onion.net using XML Schema. XML Schema is a recommendation of the World Wide Web Consortium (W3C), facing the question how to express shared vocabularies and allow machines to carry out rules made by people. It consists of a markup language that facilitates the declaration of simple and complex data types. The schema describes the types, elements and attributes. The language allows the author to create attributes that are optional or mandatory. For elements, the author can decide which are optional, how many are required and in what order.
Several more advanced features are also available in XML Schema, including: inheritance, inclusion (imports), namespaces, annotation, local & global types, attribute & element defaults and identity constraints.
XML Schema is a very powerful means to build an information model. By XML schema onion.net empowers you to deliberately construct those document types, that meet your requirements and express your ideas. For any document in onion.net it is exactly defined which items might appear in the document in which order and number, whether they have attributes and if so which, which values are permitted and which designated character references may be used.
Hard-and-fast rules are therefore established for the nature of an XML document type with XML Schema (e.g. "a zip code in Germany consists of 5 digits"). The benefit for you: you do not need to implement these rules by programming, e.g. in the user interface. Even better: such rules can be changed quite easily. All you need to do is to modify the XML Schema. As this itself is a document, changing the rule (which would mean to rewrite programme code in other products) comes down to editing a document. You can do this easily with the onion.net editor.
XML schema not only makes it simpler to treat the XML documents, but also implements a very useful W3C standard. Only few Content Management Systems have so firmly fixed W3C standards in their core.
The advantages are clear to see
W3C standards offer a very high flexibility and performance, more than any internal development, because “standard” always means widespread. In addition, implementations of these standards are freely available, meaning that an enormous number of developers with the most varied of backgrounds contribute to the implementation of any W3C standard. Internal developments cannot offer such a variety.
Integrating components which implement a standard and which continue to be constantly developed everywhere in the world thanks to their free availability, therefore leads to onion.net also continuing to be developed constantly everywhere in the world. If a new implementation has become ready for marketing and is issued by the W3C as a recommendation, it is possible to integrate the new implementation in onion.net and use its advantages with a relatively low expenditure.
More Advantages of XML schemata
The use of uniform “grammar rules” in the form of XML schemata also prevents inconsistency of the data. If a subsequent change is made to a schema, it is validated against all instances of the schema already available. If the modifications would lead to that objects already available in the system losing their validity, they cannot be stored. There are no inconsistencies.
XML schema by an example
Imagine that we have defined for an XML document type “page” in our schema that a title must be indicated first of all and that a running text can be indicated as the second element.
Yet we have already created some pages in this form in onion.net (i.e. produced instances of the XML document type “page”) and suddenly realise that we would like to create another teaser underneath the running text.
Since teasers generally have a different form than running text, it makes sense for them to have their own element in the XML schema. We now insert this item into the existing “page” schema and realise that we cannot store it.
Why? If we were to store the type with the rule that three items must be contained in it (title, running text, teaser), the already existing pages would break this rule, since they only contain the elements of title and running text.
However, if one amends the rule in such a way that a teaser can be created optionally, but does not have to be, then none of the available pages shall infringe on our document type definition any longer. We have successfully (and consistently) extended the type.