constraining a constraint placed inside a classSpec

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

constraining a constraint placed inside a classSpec

Piotr Banski
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
Reply | Threaded
Open this post in threaded view
|

Re: constraining a constraint placed inside a classSpec

Piotr Banski
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
>
Reply | Threaded
Open this post in threaded view
|

Re: constraining a constraint placed inside a classSpec

Peter Stadler
In reply to this post by Piotr Banski
Piotr,

I was only able to understand a limited percentage of your question(s), sorry – but let try to answer the following:

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

The magic you (and others) want—to refer to members of a class within your ODD—ist not implemented at present. (I vaguely remember Raff struggling with this also, so maybe he could add his use case here, as well?! )

So, the code snippet above probably does what you want, but it is by no means limited to the classSpec its a descendent of. In fact, it is applied to every element (in any namespace) with an attribute @referringMode with the value „pointer“. If this attribute may appear on other elements (than those of your class), you really need to specify those elements in the @context.

Hope that helps
Peter

Reply | Threaded
Open this post in threaded view
|

Re: constraining a constraint placed inside a classSpec

Syd Bauman-10
In reply to this post by Piotr Banski
Hi, Piotr -- remind me never to let you near our pet bunny!

I'm not at all sure I understand the problem you are suffering, if
any. But it sounds like you are bumping up against a limitation of
odds/extract-isosch.xsl: namely, that when it finds a <constraint>
that
  a) does NOT have a @context, and
  b) is inside a <classSpec>
it creates a general-purpose context, rather than doing the right
thing (which would be to run around the ODD tree and figure out which
elements are members of the class, and generate a context of only
those member elements).

E.g., Let's say you've defined a new class "att.rabbitType", which
has only one member (<pb:rabbit>). This class defines two new
attributes: @sylvilagus, a required attribute which has the possible
values "audubonii", "cognatus", "cunicularius", "floridanus",
"graysoni", "nuttallii", "obscurus", "robustus", and
"transitionalis"; and @localName, an optional attribute which has the
possible values "Allegheny" and "Appalachian". The @localName
attribute should only be used if sylvilagus="obscurus". So you create
a Schematron rule to enforce that:

   <constraint>
     <sch:report test="@localName  and  @sylvilagus ne 'obscurus'">
       Whoa! There should not be a @localName for a <sch:value-of
       select="@sylvilagus"/> rabbit!
     </sch:report>
   </constraint>

This rule *should* only be fired on <pb:rabbit> elements. But as
odds/extract-isosch.xsl is currently written it will fire for *all*
elements. While this is a performance hit, in this case (and, indeed,
in the vast majority of cases) it is not a problem, because the
@sylvilagus and @localName attributes do not exist for any other
element.

But if you named your new attributes, say, @memberOf and @subtype,
you could run into trouble, getting messages about rabbits on
elements that had nothing to do with them.


There is currently no clever way for you, the ODD writer, to say
"insert here the qualified names of the elements which are members of
this class". I'm not sure whether there should be or not. But either
way, I think odds/extract-isosch.xsl should do that for you. It is on
my list of things to fix someday, but to be honest, I had thought of
it as pretty low priority. That's because a) I thought very few
people, if anyone, would get caught by it, b) it is non-trivial to
fix, and c) the hack to get around the problem is pretty easy:

   <constraint>
     <sch:rule context="pb:rabbit">
       <sch:report test="@localName  and  @sylvilagus ne 'obscurus'">
         Whoa! There should not be a @localName for a <sch:value-of
         select="@sylvilagus"/> rabbit!
       </sch:report>
     </sch:rule>
   </constraint>

So TEI-L readers, please let me know if (a) turns out not to be the
case, and I'll try work on this sooner rather than later. (But not
before my taxes are done, in any case! :-|


> 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...
Reply | Threaded
Open this post in threaded view
|

Re: constraining a constraint placed inside a classSpec

mholmes
In reply to this post by Piotr Banski
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
>>
Reply | Threaded
Open this post in threaded view
|

Re: constraining a constraint placed inside a classSpec

Piotr Banski
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
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: constraining a constraint placed inside a classSpec

mholmes
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
>>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: constraining a constraint placed inside a classSpec

Piotr Banski
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
>>>>>
>>>
>