If you 
search the archives, somewhere in the past I explained  dimensions and 

the 
coupling effects and noted that it could be visualized in applications such as 

VRML/X3D.
 
The 
interesting effects are the coupling effects.  Semantics don't scale well 
so 
we 
tend to flatten out the rendering client data (the application language may 

be 
XML-compliant, but that is still just a format).  What is more interesting 

is for 
scale (semantic complexity) to couple to scope (data used by a domain) 

to reach (data used among domains or in 
aggregates).
 
Again, 
the decisions about the neighborhood based on the customer types 

AND 
information types are the ones that make the most difference to the 

business.   Essentially, one is choosing the personal 
productivity tools 
(eg, 
office tools such as spreadsheets, word processors, etc.) and the 

business productivity tools (domain specific tools such as the databases 

for 
the business type, the command and control tools, etc.).  Unless these 

interoperate, the business stovepipes and it gets hard to push 
business-based 
reports into office tools, and vice versa. 
 
There 
are two strategies one sees touted:
 
o  Because semantics are the hard part, choose a single platform and 
distribute 
it as 
widely as possible.   Even if proprietary, it is reliable.  Costs 
go up and 
cannot 
be controlled by the buyer but if your business is of great value to you, 

you 
can't afford not to do this.
 
o  Because semantics don't scale, choose open formats supported by 
the 
largest number of users.  Even if open source is a risk, it has the 
lowest 
costs 
and the best set of alternatives.  Costs go down and can be influenced 

by the 
buyer.  The trouble is semantics matter to the buyer because they 

determine the operations one can perform, so if the semantics are too 
limited, 
you 
can't afford to do this.
 
The 
question of cost vs operational complexity is always there.   What the 

web 
taught us is that we can do without many of those operations, and if 

we 
factor amortize costs over time, we get those operations back without 

an 
uncontrollable rise in costs.
 
In the 
long term, open always wins.  The razor for the market type is 

the 
buy cycle:  what can you buy now and sustain for how long given 

the 
minimal operational space you must cover.
 
len

  
From: Costello, Roger L. 
  [mailto:costello@m...]

  Hi Folks,
   
  [Thanks Len, you beat me to the mark.]
   
  Peter, you make a good point, an XML document that is purely transient or 
  purely persistent is likely the exception; the common cases are XML documents 
  that are a mix of transience and persistence.
   
  However, what I was trying to do was 
  to explore the "space" of possibilities for XML usage.  To put 
  it into semi-mathematical terms, I want to define the "axes/dimensions" of XML 
  usage.
   
  To summarize everyone's comments it appears that there are three 
  "dimensions" to the usage of XML:
  1. Persistent XML: the XML document is 
  persistent.  Applications operate directly on the XML 
document.
  2. Transient XML: upon arrival at its 
  destination the data may be transformed into some other format (language 
  objects, relational database, etc) that applications work with.
  3. Application XML: the XML document 
  is the application. 
  Question:
   
  Does the usage (role) of an XML document influence its design?  
  
   
  For example, are transient XML documents typically flat, whereas 
  persistent XML documents typically nested?
   
  Peter, I am still struggling how to put into the above "space" 
  your ideas on XML-and-UI.  Your assertion is that the usage of XML is not 
  a 3-dimensional space, but a 4-dimensional space?  Can you characterize 
  the fourth dimension?
   
  /Roger