[tei-council] P5 source, modifying class atts at the base level.
Laurent Romary
laurent.romary at inria.fr
Fri Sep 30 05:19:08 EDT 2011
As Sebastian knows already, I asked him exactly the same question on Tuesday. I would be all in favor that a construct like the one below:
1) would be recognized as perfectly valid for ODD (meaning we document this behaviour in the guidelines)
2) is implemented in "existing" ODD processor
@Seb you alluded to the possibility to make a first pass to check out class memberships before processing other elementSpec fields. Is this complicated?
<elementSpec ident="XXX" module="YYY" mode="add">
<classes>
<memberOf key="att.typed"/>
</classes>
<attList>
<attDef ident="type" mode="change">
<valList>
<valItem ident="xx"/>
<valItem ident="yy"/>
...
</valList>
</attDef>
</attList>
</elementSpec>
Le 30 sept. 2011 à 11:13, Sebastian Rahtz a écrit :
> James and I met this last night again.
>
> look at <abbr>. instead of being a member of att.typed, it defines its own
> @type attribute, because it wants to supply a <valList>. What one would like
> to do is say <attDef mode="change" ident="type"> inside the original source
> of P5. We can't do that now, because the processing does not support it at all,
> but in general, do people believe that it _should_ work?
>
> frankly, I have not a clue about how to implement this, but if its a serious
> problem I should try.
> --
> Stormageddon Rahtz
> Head of Information and Support Group
> Oxford University Computing Services
> 13 Banbury Road, Oxford OX2 6NN. Phone +44 1865 283431
>
> Sólo le pido a Dios
> que el futuro no me sea indiferente
>
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived
Laurent Romary
INRIA & HUB-IDSL
laurent.romary at inria.fr
More information about the tei-council
mailing list