[tei-council] brooding about override of class attributes

[Piotr Bański]

Do I understand correctly that the sore spot is mode="change" for a
derivedly (can one say that?) non-existent object?

And if so, I wonder how ugly it would be to have an optional attribute
(call it e.g. "@sourceSpec") that identifies the class whose member gets
overridden, so that the processor could reach there before signalling an
error of trying to change/replace/delete a non-existent object?

And in general, (do forgive my ignorance) is it possible to have an
imported part of a combined ODD change/replace an object that is then
elsewhere invoked with mode="change"? If it were so, perhaps that would
make such a "@sourceSpec" worthwhile?

  P.

On 28/04/12 20:30, Sebastian Rahtz wrote:
> I am tasked with making this work:
> 
>   <elementSpec ident="p">
>      <classSpec>
>        <memberOf key="att.typed"/>
>      </classSpec>
>     <attList>
>       <attDef ident="type" mode="change">
>          ….
>       </attDef>
>    </attList>
>  </elementSpec>
> 
> in the Guidelines. which is OK. but what if
> we are processing an ODD which does things with
> att.typed? if it deletes @type, do we follow
> suite for <div>?
> 
> can anyone philosophise on what the exact algorithm is
> which I have to implement?
> 
> Sebastian