Re: constraining a constraint placed inside a classSpec

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 
enough.

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 
defined elsewhere.

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,

`<memberOf key="att.pointing"/>`

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,

   Piotr



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]">
>
> Cheers,
> Martin
>
> 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"
>>         xmlns:sch="http://purl.oclc.org/dsdl/schematron">
>>   <constraint>
>>     <sch:rule context="*[@n]">
>>       <sch:report test="@n eq 'bunny'">whenever this rule is
>>             triggered, a cute little bunny dies...</sch:report>
>>     </sch:rule>
>>   </constraint>
>> </constraintSpec>
>>
>> ... 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?
>>
>> Thanks!
>>
>>   Piotr
>>
>> 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:
>>>
>>> <constraint>
>>>   <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,
>>>
>>>    Piotr
>>>
>