Re: constraining a constraint placed inside a classSpec

Hi Martin,

This is definitely a valid remark, and very true in general:

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

But in this case, I am working on a LingSIG feature request for 
inclusion in the source, so I do that in the TEI namespace on purpose, 
and I want this proposal as sleek as I can make it, so that the Council 
likes it (or, at least, doesn't hate it on first sight).

Best,

   P.

On 26/03/17 20:22, Martin Holmes wrote:
> 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
>>>>>
>>>
>