RE: [xml-dev] Build Rich Complexity from a Small Set of Well-Defined Mar

["David Lee" <dlee@calldei.com>]

I propose that the number of elements and combinators is not the most useful
metric of "complexity".
For example you can create an infinitely complex data model from set
arithmetic allowing only the empty set and sets that contain the empty
set(s) as  a primitive.
Another example, List, with only set and 4 primitives can be considered by
some to be quite a complicated language to use.

Conversely languages with a large number of primitives are not necessarily
considered complex.

I suggest you are confusing many kinds of 'complexity' in one swoop.
1) Complexity (number of) the primitive operations and atoms by counting
them.  
2) Complexity of the descriptiveness these can produce  (not necessarily by
counting them.)
3) Complexity of the task of using a language to produce a desired approach
(complexity == 'difficulty of people to figure out how to do a task given
the primitives).

Another way of looking at it is
A) There's a difference between complexity and count.   
 
B) There's a difference between the complexity of a language (number and
ways its features can be used) and the complexity of humans figuring out how
to accomplish a task.
The human body is one of the most complex systems in the universe, yet we
find it amazingly simple to do many things like for example recognize
objects and assign labels to them.




----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org

-----Original Message-----
From: Costello, Roger L. [mailto:costello@mitre.org] 
Sent: Wednesday, August 24, 2011 10:16 AM
To: xml-dev@lists.xml.org
Subject: [xml-dev] Build Rich Complexity from a Small Set of Well-Defined
Markup Combinators


Hi Folks,

Consider the digits 0 - 9. They can be combined to create an infinite number
of integral numbers, such as 256 or 14 or 190023156001200021345. Each digit
has a well-defined meaning and the rules for combining the digits are
well-defined.

Rich complexity flows from a small set of digit combinators.

Next, consider XML Schema. It is a markup language consisting of a small set
of well-defined markup combinators:

    1.  Schema
    2.  Element
    3.  Attribute
    4.  Simple Type
    5.  Complex Type
    6.  Attribute Group
    7.  Element Group

The language has well-defined mechanisms for combining the markup
combinators:

    1.  Schemas are combined using import, include, and redefine
    2.  Elements are combined using sequence, choice, or all
    3.  Complex types with simple content are extended or restricted
    4.  Complex types with complex content are extended or restricted

An infinite variety of schemas can be created using the 7 markup combinators
and the 4 combining mechanisms.

Interestingly, XML Schemas is considered to be a complicated language.
Perhaps 7 markup combinators are too many in a markup language?

When creating an XML markup language consider following this approach:

    1.  Create a small set of well-defined markup combinators. From
experience with XML Schemas, 7 or less markup combinators might be adequate.
    2.  Create well-defined mechanisms for combining the markup combinators.
Again, from experience with XML Schemas, 4 or less combining mechanisms
might be adequate.

>From that will flow complexity of great richness.

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