[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: Build Rich Complexity from a Small Set of Well-Defined MarkupCombinators
- From: "Costello, Roger L." <costello@mitre.org>
- To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Thu, 25 Aug 2011 09:18:16 -0400
Hi Folks,
Excellent discussion! Here's what I learned:
When creating a markup language:
Ensure that the combining mechanisms are simple and consistent. Avoid special case rules such as: "This markup combinator can be combined with that markup combinator except in these situations." Irregularity in combining mechanism rules leads to cognitive dissonance for the users and thus results in a complicated markup language. Here is an example of an irregular combining mechanism rule:
XML Schema has several mechanisms for combining elements:
sequence, choice, all. An element combinator can be combined
with another element combinator using any of those mechanisms
unless the two elements have the same name and different data type.
That's an example of a combining mechanism with a special case rule.
Special case rules must be avoided.
Specifying even a single markup combinator in a way that is precise and easy to understand for a large community is hard. Likewise, specifying combining mechanisms is hard. Consequently, attempting to create an XML vocabulary consisting of dozens or hundreds of markup combinators and dozens or hundreds of combining mechanisms is not reasonable. Moreover, it has been demonstrated repeatedly that a small set of combinators and combining mechanisms is sufficient for creating rich complexity. Therefore, create a small set of well-defined markup combinators and combining mechanisms. XML Schema has 7 markup combinators and 4 combining mechanisms. RELAX NG has 9 markup combinators (element, attribute, reference, parent reference, empty, text, datatype, typed value, notAllowed) and 8 combining mechanisms (sequence, interleave, choice, optional, zeroOrMore, oneOrMore, list, mixed).
What other guidelines can you provide to those embarking on creating a markup language? Rich Salz mentioned the word "orthogonal". Would someone expound upon the role of orthogonally in creating markup combinators and combining mechanisms for a markup language?
/Roger
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]