Print

Print


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