[tei-council] @TEIform

[Lou Burnard]

Sebastian Rahtz wrote:

> James Cummings wrote:
>
>> Having a place in the teiHeader to refer to an ODD...or even embed it 
>> (or this that too horribly recursive?) 
>
>
> sounds expensive...
>
>> seems reasonable.  Perhaps a URI attribute in tagsDecl?  Would such a 
>> thing point just to the ODD source or to generated schemas as well?
>
>
> oh gosh you'll start up Syd's thread again. Mind you, I don't object 
> to adding a URI hook
> linking to an ODD somewhere in the header.


This sounds useful to me. And not expensive!


>
> But let's recall James Clark's belief (strongly supported in some 
> circles)
> that an instance may have several schemata against which it may or may 
> not
> be valid. There is no one right answer. So it goes against this argument
> to associate an instance with just one {XSD,RNG,DTD}.
>

Not so sure I am persuaded by this argument. I can think of cases where 
it makes quite a bit of sense to say that a given instance *was* 
validated against a specific schema instance (or , in our case, a given 
ODD).  There is also the problem that not all schema languages support 
the same constraints of course.


> However, an ODD does some more work. In this case it defines
> relationships between used element names and TEI ur-element
> names. In some ideal world, we would extract just that info
> and put it in the header

we do that already, even in our current sublunary world. namely viz 
tagsdecl.
Hmm, we could conceivably add an attribute to that giving the canonical 
name for each element used?

> - and how would we keep it up to date
> and accurate, etc? If we use <equiv> in the manner I suggested in Sofia,
> we need external data sources to do the translation anyway.
>

Maybe its the content of the equiv element which needs to go into the 
header, rather than a pointer to the ODD itself?

> We worry that a document may become separated from its metadata,
> or the metadata lost. And? A binary program separated from its source
> happens too. Its bad. But you cannot legislate against it.
>

Not a good argument. Many binaries contain (often in excurciating 
detail) lots of information about when they were last compiled and 
against what.

> We have already accepted that the I18N work presupposes the
> ability to translate from an instance which has translated names;
> this needs an ODD, since @TEIform does not help with attributes.
>

This on the other hand is  very good argument

> In the new world where DTDs no  longer reign supreme,
> attributes with default values, like @TEIform, are an anachronistic
> pain in the neck. They arent there when you might like them, if you
> use schema processing, and they pop up when you don't want them
> (when an editor shows you a list of attributes).
>


I agree, on balance.