Re: constraining a constraint placed inside a classSpec

Hi Piotr,

I've increasingly found that I need to pre-process my ODD in various
ways before I create a schema from it, to do things like creating
valLists from taxonomies. This may be one of those situations where it's
simpler to write a little identity transform which adds your constraint
to the elementSpecs of all the elements which are members of your att
class, and add that transformation to the front of your ODD processing
chain.

I agree that it would be a good idea if ODD had a mechanism to support
this and the Stylesheets were able to process it automatically, but I
don't think it would be simple to implement.

On this bit, though:

> because the attributes are not unique across the entire TEI
> repertoire, it looks like I am getting into conflicts with attributes
> defined elsewhere.

Does this mean that you're creating your own attributes in the empty 
namespace which conflict with the names of attributes defined elsewhere 
in TEI? If so, perhaps just putting your atts in your own namespace 
would solve the problem.

Cheers,
Martin

On 2017-03-26 03:25 AM, Piotr Bański wrote:
> 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
>>>>
>>