Dear Martin, Syd and Peter,
Thank you all for your replies.
What I wanted to figure out was whether I was missing some trick that
allows us to tie the context of a constraint built inside an attribute
class only to the elements that are members of that class. You've all
figured that out correctly :-)
And you have all confirmed that this can't be done now, and that perhaps
it will be doable in the future, but I shouldn't hold my breath. Fair
Indeed, I've tried to do what Martin suggests (and what Syd considered),
but because the attributes are not unique across the entire TEI
repertoire, it looks like I am getting into conflicts with attributes
I have pondered two ways of coping with this, (1) either moving the
constraints that cause conflicts into the element spec (and then
expecting users to mode="add" such constraints to other elements that
join the class, or (2) tying them explicitly to element names, like what
Syd suggested, and then expect users to redefine that constraint (and
the class) in their ODDs. Neither solution is perfect (well, both are
kludges), but after a while of thinking it seems to me that solution (2)
localizes the problem better (because once the ODD builder decides to
add their element to that particular class, they can perform the kludge
demanded by that class, rather than look at the specs of other elements).
* * *
I'm wondering whether a temporary hash-like structure could solve this,
whereby whenever the ODD processor, while going through an elementSpec
for "element-ident.1", encounters, say,
it builds a hash with
class-ident : element-ident.1, element-ident.2, ...
so at some point, it would be
att.pointing: alt, calendar, catRef, gloss, ...
(+ whatever the user does)
and then potentially writes it out to a temporary file, readable at the
moment when contexts inside classes need to be established. I'm not
making this in any way precise because I don't know yet how the
Stylesheets work, internally. But maybe it would be an alternative to
re-scanning the entire ODD each time when odds/extract-isosch.xsl tries
to establish the context. Of course, there's always pros and cons of
such solutions, and I suspect that this one has already been considered.
Thanks and best wishes,
On 26/03/17 05:11, Martin Holmes wrote:
> Hi Piotr,
> I'm having a bit of difficulty figuring out exactly what you need; could
> you explain the real constraint you're trying to add? In so far as I
> think I understand, you want to apply a constraint to all elements that
> belong to a specific attribute class; surely that would be simple to do
> by specifying a context which filters them by the particular set of
> attributes which are provided by that class?
> <sch:rule context="tei:*[@myAtt1 and @myAtt2]">
> On 2017-03-25 07:26 AM, Piotr Bański wrote:
>> I'm sure everyone is dying to hear more about this, so here we go.
>> I have now prepared a constraintSpec that silences the warnings (traced
>> them to odds/extract-isosch.xsl in Stylesheets):
>> <constraintSpec scheme="schematron" ident="die_bunny_die"
>> <sch:rule context="*[@n]">
>> <sch:report test="@n eq 'bunny'">whenever this rule is
>> triggered, a cute little bunny dies...</sch:report>
>> ... and I feel like a real monster now. I can kill bunnies just by
>> pressing "Ctrl+V", anywhere in the tree...
>> Do I think correctly that what I need is some clever way of saying
>> something like "insert here the ident of the element which happens to be
>> added to this class", and furthermore, that there is currently no way to
>> do that?
>> PS. Erratum: In my earlier message, I meant "root node" where I said
>> "root element", and it wasn't relevant anyway...
>> On 25/03/17 04:01, I wrote:
>>> Hi again,
>>> While compiling schemas for a modification that I'm working on, I can
>>> see something like this:
>>> [xslt] WARNING: constraint for att.referring class does not have a
>>> context=. Resulting rule is applied to *all* elements.
>>> Which is very true, because I have moved some constraintSpecs from an
>>> element spec (where, I gather, the element being defined supplies the
>>> context) into a spec containing a definition of a new attribute class
>>> that the element now belongs to.
>>> I have searched the Guidelines for some examples, but failed to see any
>>> that would use "context=" with Schematron. A modified example that I
>>> earlier received from Syd has this:
>>> <sch:rule context="*[@referringMode eq 'pointer']"> ...
>>> and it works really well, but is that the magic that I need for
>>> restricting Schematron to only the elements which are members of the
>>> class that I am defining?
>>> A naive reading of the above context would suggest that the Schematron
>>> rule still applies to all elements except the root element (and then it
>>> of course filters them appropriately). So where is the trick, please,
>>> what am I missing?
>>> Thanks in advance,