[
Lists Home |
Date Index |
Thread Index
]
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
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
| 