At 08:29 AM 3/5/01 +0000, DaveP wrote:
>The capital and resource costs for the initial move need very
>careful assessment, and payback is always looked on with scepticism.
>Were a number of case studies available as reference others might
>say 'hey, that business isn't too far from ours, I wonder if....'
Well, there are any number of conference papers from SGML and XML
conferences. And there's Chet Ensign's interesting book, aimed at
mid-to-upper-level managers, *SGML: the Billion-Dollar Secret*. Too bad
that it is less than clear to the bean-counters that for these purposes,
SGML *is* XML. That's the down side of that very smart repackaging (the "X"
I can only comfort myself that Adam Smith's Invisible Hand (or is it
Darwin's?) will take care of all this in the long run.
The more immediate problem for the TEI, however (as I see it) is making the
related case within the very different culture of academic programs. It
seems to be hard for humanities programs to fathom that, far from merely
following what seems at the moment to be the cutting edge of web
technologies ("Should we do XML? Should we do Shockwave?"), it is possible
for academic projects to be *leading* the development of technologies that
have practical uses outside the academy -- and moreover, as a kind of
side-effect of investigating properly intellectual and scholarly problems.
And yet, this is exactly what TEI has done.
To add to Peter's list of what TEI needs to do to be more XML-friendly, I
submit that it might be beneficial for TEI to start looking at its models
(currently, DTDs), within the context of editorial and production workflow.
(This is not an XML issue per se, but XML technologies are flexible,
various and available enough to make such an approach more conceivable,
maybe, than in the past.) If DTDs (and other validation regimens) were
broken down and cast to into phases representing different stages of a
project, the whole technology might be more accessible. Something like:
1. Project scoping. Development of skeleton headers.
2. Data capture. Structural markup. Revise headers to document tagging
practices. Validation, testing, QA.
3. Enriching the markup. (Revise headers documenting tagging practices.)
Validation, testing, QA.
4. (could be concurrent) development/application of stylesheets, analytic
toolkit, etc. etc. Testing, QA.
The challenge would be defining these stages cleanly, while simultaneously
allowing for the necessary flexibility and adaptability. Can such a
development path be conceived as normative and applicable to all types of
projects? Does it depend on the scale of the project, the nature of source
materials, the functional requirements and expected applications? And
projects might, of course, cycle through this sequence more than once
(that's even a good idea).
Note that the TEI architecture practically reflects such an approach
already, by putting the base tag sets in one category (they would serve for
stage 2), the "topping" tag sets in another (for stage 3).
While I am definitely concerned that such a scheme might be too rigid, it
would at least help address the problem of the daunting learning curve....
Wendell Piez mailto:[log in to unmask]
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
Mulberry Technologies: A Consultancy Specializing in SGML and XML