Re: Semantic markup for tabular data

["Mark Baker" <listsub -at- analecta -dot- com>]

Dick Margulis asks,

> 1. Does XML have enough horsepower to tackle that level of recursion and
>   interdependency between data and table structure)?

I've chickened out of this discussion to this point because it has dealt
with some of the most hideously complex aspects of markup technology. My
venturing to answer now is evidence of the eternal triumph of hope over
experience.

Yes, XML does have enough horsepower to tackle that level of recursion and
interdependency. Not because XML is smart, but because it is very very dumb.
XML is just a set of rules for the syntax of markup languages. It says
absolutely nothing about what those languages mean, only what they look
like. You can make an XML tagging language to represent any data structure
at all. It may not be pretty. It may not be appropriate. The entire exercise
may not be worthwhile. But it can be done.

To put it another way, XML does not describe the structure of the content
that is marked up, it describes the structure of the encoding of the
content. A table is an encoding of a set of relationships between the items
it contains, and XML can be used to describe that encoding. Other sets of
relationships between those items may exist, and XML can be used to describe
the encoding of those relationships as well. The question of whether this
alternate encoding can be used to drive the programmatic creation of the
table depends on the relationship between the two encodings. If there is a
semantic equivalence between the two encodings, then one can be transformed
into the other. If one is richer than the other, then the richer encoding
can be transformed into the poorer one, and not vice versa. Whether or not
the structure of one or both of these encodings is described in XML is not
relevant in any way to the ability to perform these transformations, it only
determines the mechanics of how the transformation is done.

> 2. If so, is the level of effort required to execute something like that
> justified? Or would traditional manual methods be cheaper and easier
> short of a requirement for immense, rapidly changing datasets and
> instant dynamic output builds?

When asking about cost justification, it is important to remember that XML
can be used for many distinct purposes. XML describes the structure of the
encoding of the content and content can be encoded in many different ways
for different purposes. There continues to be a widespread belief that there
is a perfect semantic encoding for all data that will magically make it
available for all purposes. But this is not so. If the semantics of text
could be so easily encoded, we wouldn't need text.

In the course of this discussion, I have talked about using XML to implement
a multi-step process for information development. Others have talked about
XML as a desirable format for making information easier to search and
retrieve, others as a format for making it possible for the customer to
dynamically alter the presentation of information they are viewing.
Personally, I think only the first of there applications has real value.
Search and retrieval works very well with full-text indexing and external
metadata records. The dynamic display stuff works technically, but there is
as yet not much evidence of a demand for it.

But whatever one thinks of the relative merit of these applications, they
each require different encodings of the content. For information development
purposes, we are interested in finding regular and repeating structures that
allow us to get a benefit out of automation. Some tables meet that criteria,
some don't. The driving questions are mundane: can we generate more
information more quickly and accurately if we impose this structure. If yes,
do it. If no, don't.

For the search and retrieval applications, the questions are much more open
ended. One is in the heady world of universal categorization and the sky's
the limit.

For dynamic information products, the encodings required are specific to the
behaviors of the dynamic viewing application.

The cost justification of any particular encoding depends on the purpose for
which it is intended. XML is just one available tool for describing the
structure of those encodings.
---
Mark Baker
Analecta Communications
www.analecta.com
+1 613 614 5881


^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

SEE THE ALL NEW ROBOHELP X5 IN ACTION: RoboHelp X5 is a giant leap forward
in Help authoring technology, featuring Word 2003 support, Content 
Management, Multi-Author support, PDF and XML support and much more! http://www.macromedia.com/go/techwrldemo 

>From a single set of Word documents, create online Help and printed
documentation with ComponentOne Doc-To-Help 7 Professional, a new yearly
subscription service offering free updates and upgrades, support, and more.
http://www.doctohelp.com

---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.