Re: [xml-dev] Evaluation Criteria for Markup Languages

[Michael Kay <mike@saxonica.com>]

Very often XML is used to convey data which itself is a model of 
reality. If reality is complex, then the rules for the data may also be 
complex. An important criterion for assessing the markup language is not 
whether or not it is complex, but whether or not it is an accurate model 
of reality.

For example, the real-world "rules" for personal names and addresses are 
incredibly complex. If you assess a vocabulary for names and addresses 
by its complexity, then you may end up deciding that the best vocabulary 
is one that is in fact incapable of modelling the real world.

Of course, producing a simple model of a complex reality is a desirable 
goal; it's a process called abstraction and it's the key to all good 
design. But there's a difference between being simple and being 
simplistic, and it's very fine line between the two.


Michael Kay
Saxonica


On 28/08/2011 23:17, Costello, Roger L. wrote:
> Hi Folks,
>
> I propose the following two criteria for evaluating XML markup languages.
>
> -------------------
> Criterion #1
> -------------------
> Markup languages must clearly distinguish between:
>
> - Markup for expressing individual concepts, i.e., markup combinators.
> - Mechanisms for combining markup combinators. When markup is combined, the meaning of the combined markup must be specified.
>
> Analogy: each digit 0 - 9 expresses an individual, well-defined concept. The digits may be juxtaposed and the meaning of the combined digits is well-defined. Thus, each digit is a digit combinator and juxtaposition is the mechanism for combining them.
>
> Example: XML Schema does a good job with this criterion. For example, xs:element is clearly markup for expressing individual concepts, and xs:sequence is clearly a mechanism for combining them. The meaning of the combined elements is that they possess a sequential ordering.
>
> Example: The Extensible Business Reporting Language (XBRL) does a fantastic job of separating markup combinators from the mechanisms for combining them. In XBRL the markup combinators are defined in an XML Schema and the mechanisms for combining them are specified in a separate XLink document.
>
> -------------------
> Criterion #2
> -------------------
> The rules defined in markup languages must be general. Scientists and mathematicians are never satisfied with principles or theorems that apply in only some cases. They seek general rules. So too, markup language designers must seek general rules for combining markup. Rules that apply only some of the time--that is, rules with exceptions--must be avoided.
>
> Example: XML Schema does not do well with this criterion. Many of its rules have exceptions. Here are examples of rules with exceptions:
>
> Rule: a xs:sequence contains any xs:elements.
> Exception: if two xs:elements have the same name but different data types then they cannot both be in xs:sequence.
>
> Rule: The value of the base attribute in<xs:extension base="...">  must reference a xs:complexType.
> Exception: if the parent of xs:extension is xs:simpleContent then the value of the base attribute may reference either a xs:complexType or a xs:simpleType.
>
> John Cowan reports that XML Schema has nearly 100 rules with exceptions. These make the language difficult to use and understand.
>
> Comments?
>
> /Roger
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>