• From: "Jeremy H. Griffith" <jeremy@o...>
• To: "xml-dev@l..." <xml-dev@l...>
• Date: Wed, 28 Aug 2013 10:15:42 -0500

On Wed, 28 Aug 2013 13:08:00 +0000, "Costello, Roger L." 
<costello@m...> wrote:

>Infinite replication is lousy, especially if it's replication 
>of something that doesn't fit anyone well.
>
>Forcing everyone to use the same XML vocabulary to describe 
>different use cases is really bad.

Well said.  We've seen this in action in DITA, where users
spend a remarkable amount of time trying to decide which of
two tags fits their usage better, when the truth is neither
of them really fits it at all.  Why not make a third tag?  
Because it's not in the "standard", and because in DITA
specialization is expensive in terms of time to prepare 
the arcane set of DTD modules needed to implement it.

>I suggest for your consideration the following approach 
>to designing XML Schemas: create an XML Schema that 
>contains a smorgasbord of well-defined, semantically-rich 
>elements. Then, work with your users to create XML instances 
>by picking and choosing elements that are meaningful to 
>their specific needs.

We are currently creating a markup language with similar
intentions but a somewhat different implementation.

First, we are basing it on MicroXML for simplicity; our
first step was to write a fault-tolerant parser.

Second, we don't use any schemas; we define a vocabulary
in MicroXML itself by specifying for each element the
name, properties, and attributes available, like this:

 <element name="table" props="doc table start">
  <usage>Table with rows and columns</usage>
  <attr name="order" type="enum: row col" default="row"/>
  <attr name="rows" type="num"/>
  <attr name="cols" type="num"/>
  <attr name="width" type="size"/>
 </element>

So creating a new element is as simple as copying an
older one that is processed the same way, and adjusting
attributes as you need.  (There's a set of 20 common 
attributes predefined, so most elements don't need to
specify their own.)

The processor just needs to understand the props (total
of 58 of them) to know what to do.  The mappings from
elements in context to presentation formats are in files
users can easily edit, like this:

[BlockFormatMaps]
title^map/*=BookTitle
subtitle/map/*=SubtitleTitlePage
title/chapter/map/1=TOC1

This provides a huge amount of flexibility, especially 
since without fixed content models, users can apply the 
elements any way they please.  It's up to the processor
to do something reasonable with the result, often guided
by user-set options:

[RelatedLinks]
AppendLinksToTopics=Yes
GenerateALinks=Yes

We've come to this after working with DITA for several
years, first creating the main product used to make
unstructured FrameMaker files into DITA, Mif2Go, and
then creating a similar processor for DITA source,
DITA2Go.  We are applying that expertise to create 
what the users on the DITA bleeding edge have shown us 
they really need.

There is plenty of room for more initiatives of this 
sort.  We've been using this markup ourselves for a
while, and once we're happy with the implementation,
the format itself will become public domain.


-- Jeremy H. Griffith <jeremy@o...>
   DITA2Go site:  http://www.dita2go.com/

• Follow-Ups:
  • RE: Do you enjoy neighborhoods where every house looksthe same?
    • From: "Costello, Roger L." <costello@m...>

• References:
  • Do you enjoy neighborhoods where every house looks the same?
    • From: "Costello, Roger L." <costello@m...>