[tei-council] note in sourceDesc

[Martin Holmes]

On 14-03-12 11:19 AM, James Cummings wrote:
> On 12/03/14 17:57, Martin Holmes wrote:
>> I think dropping DTDs would mean a move to P6. Lots of people still use
>> them, and will complain if they disappear from P5.
>
> We've never added it to our list of thoughts about things that
> might need P6 at http://wiki.tei-c.org/index.php/P6-dev

I've added it now.

> There is a difference between us stopping to cater for DTDs
> inherently in our releases and making it impossible to generate a
> DTD from the (potentially lossy) Relax or W3C Schemas.  I'd like
> ODD to be able to document our intention of how we are using the
> TEI even in cases where that is unable to be expressed in any
> current schema language.

Yes to the latter -- whether a schema language, or combination thereof, 
can support what we imagine for Pure ODD is partly a matter of time and 
partly of ingenuity (it's amazing what you can do with Schematron), but 
I do like the idea that we imagine first and implement at leisure. But 
the fact that we _could_ provide DTDs with impoverished functionality 
(enabling people to produce TEI files which validate against their DTDs 
but not against tei_all.rng) is not a reason to do so.

>> Whether the Pure ODD stuff justifies a P6 would depend on whether we
>> actually made use of that functionality in the standard. If we ourselves
>> define two separate content models for <p>, one for the header and one
>> for <text>, then I think the backward-compatibility problem would be
>> significant enough to warrant a change. If we just provide this
>> functionality for customizers to use themselves, then it wouldn't.
>
> Yes, that is what I mean, if EpiDoc, for example, then decided to
> make use of it for their community then that isn't a problem,
> likewise if Lou decides to use it for a project -- as long as
> what they are doing, of course, provides a pure subset. ;-)

That only matters if they want to be compliant. But Pure ODD mechanisms 
could allow two approaches: anything goes (put <div> in <p> if you 
want), or TEI-compliant (constrain your <p> in different ways depending 
on context, but make sure it's a subset). An ODD processor could enforce 
this.

>> So we could envisage a process where we put the changes in place to
>> support this, in the existing P5 universe, without using it ourselves;
>> then when we come to P6, we can take full advantage of it to build a
>> more sophisticated document model.
>
> By 'using it ourselves' you mean enforcing it in tei_all?

Yes: if we were to take advantage of the feature for generating the 
standard TEI schemas, I think we'd have to move to P6, but if we just 
make it a tool for customizers, we wouldn't.

Cheers,
Martin

> Not
> doing that, but allowing it in stricter customisations seems fine
> to me. (i.e. if it is allowed in tei_all then we aren't breaking
> backwards compatibility yes.... customisations have always been
> free to remove elements from content models and rewrite them as
> tighter subsets.)



>
> -James
>