> Really? I presume that a consumer of a TEI document that uses a
> stock schema should be able to process the document without access
> to the ODD.
No! And I daresay "of course not". While there are certainly some
processes for which this is reasonable, it is always the case that
some if not a lot of the semantics of a document are tied up in the
language in which it is encoded. And TEI out-of-the-box does not
really provide a complete, ready-to-use markup language. It provides
an excellent framework and documentation (and even some software) for
creating and using a markup language based on TEI. (A
<soCalled>TEI-conformant</soCalled> language -- and that's so-called
because the notion of conformance really applies to documents, not to
the language to which the document adheres.)
You are poking at the idea that since the TEI language is a published
one, perhaps a user should not have to read your customization ODD in
order to process your document. Perhaps just reading the TEI
Guidelines should be sufficient. And while this isn't a crazy notion
(after all, you can mostly do that with DocBook), TEI is way too
broad a system to make this feasible. For better or for worse, the
TEI has been very clear: lots of the semantics of a document are tied
up in its customization ODD.
Moreover, think carefully about these "stock schemas" of which you
speak. TEI provides tei_all as a sort of "catch none" vanilla schema
to show you all the things TEI *can* do. It provides TEI Lite, TEI
Tite, and TEI in Libraries as various customizations for actual use,
in which you will find definitions of @type (at least in some cases).
It provides quite a few "stock" ODD files to show you a bit about how
to make an ODD. But none of these (except perhaps for Lite and Tite,
and I would argue not even those) are really intended to be used for
encoding documents straight up.
> Moreover, we often comment on how positively un-controlled
> idno/@type vocabulary is. (Should it even be data.enumerated?)
> Should there really be no structured way for a document to announce
> what the abbreviations used in idno/ @type mean?
Yes, I think it would be better to have a way to express controlled
vocabularies in the <teiHeader> for use on various attributes. In
the past I (unsuccessfully) pushed for the use of data.code for this
But that said, the current system isn't so bad. Especially (as
Laurent pointed out) if you take advantage of <equiv>. There *is* a
well-structured way. It just involves multiple files. (Note that
James has recommended that the ODD be stored in the <teiHeader>, thus
alleviating the multiple file problem.)
My 2008 Balisage paper was about this topic.
> Just as the encodingDesc provides a structured mechanism to record
> the expansion of other terms, why not so for idno/@type?
An <idnoDecl>? :-)
> Couldn't all the wisdom gathered after dealing with XML namespaces
> for a couple decades be applied to idno namespaces?
Not sure what wisdom you have in mind, here.
... gotta run ...