On 8/23/2011 6:37 PM, Sebastian Rahtz wrote:
> On 23 Aug 2011, at 23:22, Wendell Piez wrote:
>> a way I expect it to be processed. But presumably the TEI
>> Consortium could refuse me the use of namespace
>> "http://tei-c.org/ns/experimental/wendell2011a" until I
>> demonstrated the utility and suitability of my nifty new tag set
>> for others (maybe meeting a two-implementation requirement?),
>> documented it to its standards with worked examples, and offered a
>> dumbing-down transformation into 80% TEI to accommodate anyone who
>> didn't want to support the tagging natively.
> I think there is a lot of merit in the development of best practice
> in this area; I think the respectable projects which seriously
> customize the TEI do exactly this already.
Hm. This may be true, but I am troubled by your characterization of
those who don't make the grade here as not "respectable". There may be
reasons why a project doesn't do this apart from moral lapses. Maybe
they don't have the resources. Maybe they don't have the know-how, or
not yet. Maybe they have other priorities that intervene.
I think the larger question faced by the Council (and possibly the
Board) is whether this status quo is good enough. It is (I think)
* "Blind interchange" at present, or even something more like it, is
hindered by the permissiveness and size of the current TEI-all tag set
(all the 550-odd elements in the http://www.tei-c.org/ns/1.0 namespace).
Mind you, I am not saying it would be easy in any case. But I don't
think things have to be as difficult as they are in TEI, either.
* Stress is felt on both sides, both by parties who want to use TEI but
can't do so effectively out of the box because it offers too much, and
by those to whom it gives too little (because 550-odd elements is a
small constellation within the galaxies of possible encodings, even
reasonable ones of interest within the domain of the TEI).
In brainstorming mode, what I'm essentially suggesting is that the first
problem can be dealt with by deploying a much more constrained tag set
specifically to meet the interchange requirement (if not perfectly, then
at least better than at present). As Lou remarks, the need for
this has been felt ever since P3, and occasionally addressed, by
profiles such as TEI-Lite; but as long as it is not "the" TEI, I don't
think any of these will ever get much traction for the "blind
interchange" problem. Julia points to shortcomings in the profiles
themselves, but I am not sure this is a sufficient explanation. It's
true that the design problem is not trivial: I suggested a somewhat
heretical approach to it this year at Balisage. A critic might point out
that my suggestion to rely more on what Michael Sperberg-McQueen calls
"control points for extension in the instance" -- something TEI already
has in plenty -- amounts to dealing with the interchange problem not by
solving it but by exposing it: rather than trying to make the problem
points go away (they won't), I'd like to see normative interfaces to
them. I think even that would be an advance.
And if such a tag set (plus constraint set) were ready, it could be
blessed with a TEI namespace tomorrow. A distinct namespace would make
the boundaries clear for both users and developers, while allowing a
clean separation for processing. One of the ways to foster interchange
is by dramatizing when the constraints that guard it are violated. At
present, it is too easy to say "well it's valid to TEI-all" and put the
problem off for another day.
On this basis, the second problem could be addressed by providing a
formal mechanism for developers to receive TEI support, approval and
imprimatur for markup design initiatives, only *outside* the core. Build
on what already happens in the SIGs, only conceive the goal as something
other than "becoming TEI" by adding new modules to TEI-all.
Really the TEI has two means of motivating its participants: the carrot
of recognition and approbation (perhaps accompanied by a travel
allowance), and the stick of shame.
We know about the stick of shame; we wield it ourselves without even
knowing it (for example, when we characterize only some TEI projects as
"respectable" based on abstract criteria without reference to any
particulars.) But recognition and approbation are much harder to come
by. Projects must perform X, Y and Z gestures and genuflections even to
be "conformant" and "respectable" -- over and above what is needed for
their own actual goals (and what might otherwise constitute more
substantive contributions to the state of the art). As for approval, it
appears that the only way a developer can receive that is to become
enough of an activist that they can promote their initiatives into the
core -- thereby becoming part of the problem, since (whatever the merits
of the particular applications supported) further bloat and more options
only make it harder for those who come behind (to say nothing of making
for a "standard" that won't sit still). And paradoxically, by putting so
much weight on the "standard-making" part of the activity, the
organization ends up neglecting a problem like interchange.
If, instead, good developers could lead by example without having to
play the zero-sum game of whose proposals claim enough attention and
approval from the maintainers to get into the core, there would be less
fear of the stick of shame and more room for experiment and Initiative,
with carrots all around.
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