Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#202 Allow certainty etc. in "empty" elements

AMBER
closed
nobody
5
2010-02-11
2009-09-19
BODARD Gabriel
No

It is suggested (as per discussion on TEI-L this week) that we allow elements such as 'certainty' and 'precision' to appear inside the "empty" elements such as gap and space.

<quote>
One of the advantages of the new method of pointing from elements like
<certainty/> and <precision/> is that we can use simple XPaths in @match
to point to one or more target elements, rather than having to use the
(always slightly cumbersome[*]) @xml:id on target element and
@target="#{that id}". In an ideal situation, I would now simply pop the
<certainty/> element inside the target element, and say @match="..", but
for this to work <certainty/> and <precision/> would need to be
allowable more globally than now.

In particular, the elements to which I most often need to attach
certainty and precision statements are <gap/> and <space/>, which have
very limited content models that don't seem to include elements from the
certainty module.
</quote>

In addition, it has been suggested (by Stuart Yeates among others) that the guidelines need to be clearer on the usage of @match to contain XSLT/XPath, namely:

<quote>
It seems to me that the guidelines need to be clearer on this. Maybe we
could add to the @match note:

----
The tendency of documents to be edited and evolve should be taken into
account when choosing how to encoding the pointer. @match is meant to be
used with patterns such as:
<certainty locus="name" degree="0.7" match="//div[@type='checked']//persName"/>
or
<certainty locus="value" degree="0.3" match="//note[@resp='#JC']" />

Patterns such as
<certainty locus="value" degree="0.3" match="//div[3]/p[6]/name[2]" />
are usually best encoded using a @target, because they are very fragile
in the face of document editing.
</quote>

Discussion

1 2 > >> (Page 1 of 2)
  • BODARD Gabriel
    BODARD Gabriel
    2009-09-22

    I should withdraw the first part of this FR, as I have only just caught up with Wendell's useful points about XSLT vs. XPath context.

    If someone can clarify that it really is not considered useful to allow anything like @match='..' to point to an element from the context of the <certainty/> element, then I'll remove this from the FR and just leave Stuart's suggestions for improving the guidelines.

     
  • Lou Burnard
    Lou Burnard
    2009-10-01

    Following the discussion on TEI-L, I'd say that we clearly haven't quite got the definition right yet, and that it would not be generally considered advisable to use @match in the way you originally proposed. I think Council needs to think about the issues raised by Wendell and then propose revisions taking into account those criticisms and also your very real use-case. Stuart's revision is OK as far as it goes, but post-Wendell, I'm now wondering about the wisdom of our view that there is an implicit context for the @match value which can be overridden by means of the // in Stuart's examples; maybe the context for @match should *always* be the document root. Otherwise, if we permit other context, there is no logical reason not to permit the ../ variant you propose.

     
  • Lou Burnard
    Lou Burnard
    2009-10-01

    • milestone: --> AMBER
     
  • Lou Burnard
    Lou Burnard
    2010-02-07

    • status: open --> closed
     
  • Lou Burnard
    Lou Burnard
    2010-02-07

    Closing this ticket for now, following extensive revision and redefinition of @match

     
  • BODARD Gabriel
    BODARD Gabriel
    2010-02-07

    Now that ticket #2877940 has been resolved, and we have a definition of @match that approximates what I had erroneously believed it to be in the first place, I think it is now appropriate to reopen my original request in this ticket, namely:

    <quote>
    One of the advantages of the new method of pointing from elements like
    <certainty/> and <precision/> is that we can use simple XPaths in @match
    to point to one or more target elements, rather than having to use the
    (always slightly cumbersome) @xml:id on target element and
    @target="#{that id}". In an ideal situation, I would now simply pop the
    <certainty/> element inside the target element, and say @match="..", but
    for this to work <certainty/> and <precision/> would need to be
    allowable more globally than now.

    In particular, the elements to which I most often need to attach
    certainty and precision statements are <gap/> and <space/>, which have
    very limited content models that don't include elements from the certainty
    module.
    </quote>

    Any objections to allowing certainty, precision, etc., inside <gap> and <space>?

     
  • BODARD Gabriel
    BODARD Gabriel
    2010-02-07

    • status: closed --> open
     
  • Lou Burnard
    Lou Burnard
    2010-02-10

    The easiest way of doing this would be to add certainty, precision, and respons to model.glossLike.

    This would have the interesting side effect of making it possible for these three elements to self nest -- so that you could talk about the preciion of the certainty, or the certainty of a certainty of a certainty... hmm. Or we could put in some schematron rules to prevent such headaches.

    <space> doesn't currently have a content model of model.glossLike, so that would need to be changed.

     
  • BODARD Gabriel
    BODARD Gabriel
    2010-02-10

    <quote><space> doesn't currently have a content model of model.glossLike, so that
    would need to be changed.</quote>

    I would actually be in favour of that anyway, since our usage of <space> is almost completely parallel to <gap>. (if a gap can have a prose description such as "lines omitted because considered extraneous", why shouldn't a space have a prose description such as "left blank on stone because next word very long", or something?)

    But more to the point, would it do any *harm*?

     
  • Lou Burnard
    Lou Burnard
    2010-02-11

    At rev 7187, added the three to model.glossLike; also changed content model mof <space> to zeroOrMore model.glossLike

     
1 2 > >> (Page 1 of 2)