A couple more comments on the authoring issue:

At 06:12 PM 10/13/2003, Sebastian wrote:
> >  are there any plans to create special recommendations for this
> > use (perhaps the focus for a Special Interest Group in that case?), or
>
>I proposed a SIG for Nancy on the subject

I wish I could come to France (for more than one reason) ... :->

> > is this all seen as peripheral to TEI's main objectives?
>
>I don't think so. Perhaps I am biased, as I it is my own main use of the
>TEI :-}

Likewise, I think this was always in scope, at least conceptually or
potentially, and Sebastian isn't the only one who authors this way.

>don't forget the TEI Guidelines themselves are a TEI document, which is
>rendered as a set of web pages.

Right.

On the other hand (speaking for the Legions of Hell here), it is still a
reasonable question whether the TEI, or your favorite TEI subset, is
well-suited to be an authoring tag set for a user who is not, like
Sebastian, an expert both in TEI concepts, categories and tag usage, and in
XSLT, HTML, XSL-FO and the rest. Sitting down and knowing which of umpteen
different inline tags is the correct one for a given situation is just
different if you know those tags already. And even more different if you
know exactly how to extend your stylesheet to answer an unanticipated
processing requirement. For a neophyte, even determining whether a given
processing requirement has already been addressed can be hard; it's not so
hard for the guy who built the system. :->

The perennial tools issue is related to this, but even apart from "good
tools" the question of a strong design is a fair one.

> >  For
> > example, does <text> mean the same if you're marking up 'Persiles y
> > Sigismunda' by Cervantes as it does when you're marking up a Spanish
> > Departmental website using TEI?
>
>well, I'd argue it does, yes ...

And there's the rub.

In an authoring tag set, there is simply no higher authority than the
author who pens the work. Sebastian's <text> is the same both times. But if
I turn it around, deploying some element in a way that's legal but not
"normal" (or that's semi-legal, but happens to work with my stylesheet),
who's to say that's "wrong"? The question of what's "tag abuse" is much
more vexing when there's nothing to refer back to.

> > At the moment we have two approaches to publishing TEI documents.
> > Increasingly we are drawn towards the Cocoon model,
>
>don't forget AxKit as well as Cocoon.

And there are others as well (lately I've been doing stuff with a Python
server suite, 4Suite).

>are you saying you view the whole web as one giant TEI document? that's
>quite hard work, though laudable. I go for a simpler solution, whereby
>each web page is a separate <TEI.2> document, and is rendered on its
>own. Conceptually, I could wrap the whole site in a <teiCorpus.2> but
>the only thing it would buy me is interpage linking

A robust authoring tag set should support either approach. Sometimes
interpage linking is not a trivial benefit.

> > * central parameters that control output destination and linking
> > structures
> > * creation of filenames/folder structure
> > * creation of navigational elements
> > * some degree of image management
> >
> > These XML files are not, at present, in TEI. Can anyone give me any
> > advice as to how an integrated TEI solution might deal with this kind of
> > thing?

Indeed!

>I am not sure what problem you need a solution to. Things like linking
>up the pages, writing multiple output documents, managing navigation
>etc, are all XSLT problems; which would apply just as much if you used
>Docbook as TEI. What sort of things would you suggest need changes in
>the XML itself?

Well, tag sets such as DITA (IBM's topic-driven technical documentation tag
set -- which does web site generateion, indexing and other functionalities)

at http://www-106.ibm.com/developerworks/xml/library/x-dita1/

or Apache's Forrest (http://xml.apache.org/forrest/index.html)

-- to say nothing of DocBook -- have given thought to at least some of
these problems and solutions.

But note: just said: quick and dirty is usually better than perfection
delayed indefinitely. There comes a point when more detailed requirements
analysis doesn't get you further, and you just have to task your expert
subcommittee, then trust them.

I wish I could be at Nancy! (I wish I had more time for this kind of project!)

Cheers,
Wendell



======================================================================
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
======================================================================