[tei-council] Mode attribute for <classes>
Lou Burnard
lou.burnard at oucs.ox.ac.uk
Mon Sep 3 11:23:39 EDT 2007
Nothing could make Sebastian looser than he already is. However, even
though Laurent has magnaminously withdrawn this suggestion, I think we
could consider doing something along those lines.
Firstly <classes> does not need to have an identifier, because only one
occurrence is permitted within an <elementSpec>. So there is no real
problem in putting a @mode on it. This is not however true of <memberOf>
elements, which *do* repeat and are *not* identifiable. But I see no
need to give them a @mode attribute anyway.
<classes mode="add"> means "add my parent to the classes indicated by my
children without changing its existing memberships"
<classes mode="delete"> means "remove my parent from the classes
indicated by my children"
<classes mode="replace"> means "replace my parent's existing class
memberships by those indicated by my children"
<classes mode="change"> means the same as mode="add", except that it
should raise an error if my parent has no class memberships.
Am I missing something? This seems neither too hard nor too inconsistent
with what we currently have.
Laurent Romary wrote:
> OK. Making the thing nicer is not worth making Seb loose a whole week.
> Just Imagine I had said nothing...
>
> Le 3 sept. 07 à 17:06, Sebastian Rahtz a écrit :
>
>> Laurent Romary wrote:
>>> My point was to have the same mechanism for modifying class
>>> relationships as we have for other aspects of an elementSpec.
>>> In the current version, the only way to change the classes attached
>>> to an element is to make a complete <classes> declaration with all
>>> new and old classes.
>> yes, because it is not identifiable. <classes> is a black box like
>> <desc>, you either take
>> it away or replace it. Within <classes>, <memberOf> is not
>> identifiable either, ie
>> it has no @ident.
>>> Beyond the fact that it is not coherent with the rest of the
>>> specification mechanisms
>> technically, it is :-}
>>> it prevents anyone to know what is actually deleted or added from the
>>> initial declaration. I would thus suggest to add a mode attribute
>>> both for <classes> and <memberOf>, with the following meaning:
>>> - <classes mode="change"> means look inside at he mode attributes of
>>> the embedded <memberOf> (see below).
>>> - <classes mode="delete"> means all <memberOf> declarations have to
>>> be removed from the existing element specification
>>> - <classes mode="add"> means all <memberOf> declarations should be
>>> added to the existing element specification
>>>
>> I _could_ do that, but it would conflict the semantics of @mode elsewhere
>>> - <memberOf mode="add"> means the relation should be added to the
>>> existing element specification
>>> - <memberOf mode="delete"> means the relation should be deleted from
>>> the existing element specification
>> ditto.
>>>
>>> This specification allows the same thing to be expressed in two
>>> different ways, for instance an addition and a deletion could be
>>> either expressed as
>>> <elementSpec>
>>> <classes mode="change">
>>> <memberOf mode="del" key="X"/>
>>> <memberOf mode="add" key="Y"/>
>>> </classes>
>>> </elementSpec>
>>> or
>>>
>>> <elementSpec>
>>> <classes mode="del">
>>> <memberOf key="X"/>
>>> </classes>
>>> <classes mode="add">
>>> <memberOf key="Y"/>
>>> </classes>
>>> </elementSpec>
>>
>> <classes> cannot appear twice, I think.
>>
>> I am extraordinarily reluctant to get into implementing this
>> proposal, because it would lose a week of my life. But I will,
>> of course, if everyone says it is needed, and are willing to accept
>> the contradictions.
>>
>> --Sebastian Rahtz Information Manager, Oxford University
>> Computing Services
>> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
More information about the tei-council
mailing list