[tei-council] display of modified arts in P5

[James Cummings]

On 14/01/13 13:45, Martin Holmes wrote:
> On 13-01-14 03:54 AM, Gabriel Bodard wrote:
>> On 2013-01-14 11:49, James Cummings wrote:
>>> On 14/01/13 11:26, Sebastian Rahtz wrote:
>>>> no, there is not a _promise_ that its a subset change only.
>>>> its possible that we might use this to open up a data type?
>>>
>>> Wouldn't that be breaking our own rules on Conformance?
>>
>> I don't see why. It's not as if TEI has a global rule that @type must be
>> a data.name, whether it's defined in att.typed or elsewhere on an
>> elementSpec. If we did have such a rule, then any local schema that
>> loosened the datatype would be breaking conformance with the TEI as a
>> whole, but if we define it differently in one case, that's the thing
>> people need to be conformant with, surely?
>
> If a previously-valid document now fails to validate against tei_all due
> to a datatype change, then we would be breaking backwards compatibility.
> Is that perhaps what James meant?

No, I was confused.  As part of our Conformance guidelines we say 
it is fine to tighten up a specification (e.g. reduce the content 
model, constrain attribute values), but that loosening them so 
you've extended it in a way that something valid against your 
schema isn't valid against tei_all breaks the abstract model. You 
guys are right that we make the rules and this isn't the case.

However, this is precisely the instance where I think an 
attribute _shouldn't_ be inherited from a class.  If we are 
loosening/changing the content model so that something using this 
attribute would not validate for other uses of this attribute in 
the class, then that is a clear argument for me that it should be 
created locally.  So I would only use this in-place modification 
where we are subsetting, refining the definition, or constraining 
the attribute's valList. If we're using it to make it looser then 
I don't think it is a member of the class any more.  Or if you 
want a new conundrum, why do this rather than make the attribute 
class as a whole looser and tighten it up in all the *other* 
places rather than this one.

Of course I could be continuing to misunderstand,

-James


-- 
Dr James Cummings, James.Cummings at it.ox.ac.uk
Academic IT Services, University of Oxford