Support for @context

[lb42]

The attribute @context "supplies an XPath identifying a context within which this component of a content model must be found" : it's part of the class att.repeatable, and available therefore on alternate classRef elementRef and sequence. However it's not been implemented and there's no example in the GL showing how it's supposed to work. There is however some indication in published articles about the ODD language. For example , the following (from Rahtz & Burnard "Reviewing the ODD system" available from https://ora.ox.ac.uk/objects/uuid:56d1bcff-a6ae-45bd-90db.../ATTACHMENT01)

"At present ISO Schematron rules allow us to define such contextua rules, and something analogous to them is provided by the W3C Schema notion of base types. Suppose, however, that an XPath-valued @context attribute were available on any of the elements <elementRef>, <macroRef>, or <classRef> restricting its applicability. Thus, the content model for <p> might say something like

<elementRef key="s" context="ancestor::text" minOccurs="1"/>
<macroRef key="macro.limitedContent" context="ancestor::teiHeader"/>

to indicate that a <p> within a element must contain one or more <s> elements only, whereas one within a TEI Header must use the existing macro definition limitedContent."

That example is invalid because (for no reason that I can see) <macroRef is not a member of att.repeatable and so doesn't have @context. But even if it said (say) <elementRef key="textNode" context="ancestor::teiHeader"/> , the stylesheets currently could not handle it.

Council needs to discuss whether to
a) remove this attribute silently
b) retain the attribute but hedge it round with a warning that it doesn't currently do anything
c) retain it and make it available on macroRef
d) retain it and make it work e.g. by auto generating additional schematron
e) some fifth thing I haven't thought of

[raffazizzi]

F2F subgroup suggests to silently drop (a).

[hcayless]

Kill it with fire. Look into other ways of having more expressive constraints in Pure ODD

[lb42]

What's wrong with this particular way of "having more expressive constraints in Pure ODD" ? I think (b) is a plausible choice above: it's good to have a reminder that the GL spec for ODD is not all necessarily implemented in the current generation of tools. Certainly the use case (e.g. <p> having a different content model inside <teiHeader> from that it has inside <text>) is pretty well established/recognised. But I defer to Council's wish for an easy life.

[hcayless]

There's nothing wrong with it, but we don't see how it can possibly work as advertised. Now, if we wanted to come up with a way to have context-based content models, I'd be all for it, but we can't see how this wouldn't be just an unholy mess. So we like the general principle, but think this way of implementing it is flawed.

[hcayless]

Removed in caf570c