Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#204 Revisit use of @target, @match on certainty, precision, etc.

AMBER
closed
nobody
None
5
2010-02-01
2009-10-13
BODARD Gabriel
No

tba

Discussion

  • In the P5 guidelines, the note on <certainty>'s @match attribute states: "The context for the
    pattern is the nodeset identified by the value of the target attribute. If no value is given for
    target, the context is the document root element."
    (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-certainty.html) We would like to suggest
    that the definition be changed so that in the absence of a @target defining the context, the
    default context is the <certainty> element itself. This would enable @match to use XPaths relative
    to the element to which it is attached, such as match=".." to refer to the parent of <certainty>.
    This is already legal if <certainty> has an @xml:id and @target points to it. So

    <lem resp="7.18">σημ<unclear>α</unclear><supplied reason="lost" cert="low">σί</supplied><unclear>α</unclear><certainty xml:id="foo" target="#foo" match=".." locus="value"/></lem>

    is currently perfectly in line with the guidelines (see Lou Burnard's message in a thread on TEI-L:
    http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0909&L=TEI-L&T=0&F=&S=&P=15221\). Our
    suggestion would simplify

    <certainty xml:id="foo" target="#foo" match=".." locus="value"/>

    to

    <certainty match=".." locus="value"/>

    removing the need to generate xml:ids for every <certainty> element. Since the document root is
    easily referred to in an XPath expression (i.e. "/") there is really no need to make it the default
    context, especially since this removes the ability easily to refer to other nodes in the document
    from the <certainty> element itself.

    This change would require no schema alterations. The only change needed would be to the text of the
    guidelines.

    In the thread on TEI-L referenced above, Wendell Piez voiced some objections to the use of @match,
    based on its similarity to XSLT's @match, which can only contain absolute XPath patterns. The use
    of a new attribute (perhaps @select, like XSLT @select) was suggested, but since there is already a
    @select attribute in the att.global.linking module, we would prefer to modify the definition of TEI
    @match instead. A further note in the guidelines stating that TEI @match is not XSLT @match
    might be warranted.

     
  • (Same as above with formatting fixed)

    In the P5 guidelines, the note on <certainty>'s @match attribute states: "The context for the pattern is the nodeset identified by the value of the target attribute. If no value is given for target, the context is the document root element." (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-certainty.html) We would like to suggest that the definition be changed so that in the absence of a @target defining the context, the default context is the <certainty> element itself. This would enable @match to use XPaths relative to the element to which it is attached, such as match=".." to refer to the parent of <certainty>. This is already legal if <certainty> has an @xml:id and @target points to it. So

    <lem resp="7.18">σημ<unclear>α</unclear><supplied reason="lost"cert="low">σί</supplied><unclear>α</unclear><certainty xml:id="foo"target="#foo" match=".." locus="value"/></lem>

    is currently perfectly in line with the guidelines (see Lou Burnard's message in a thread on TEI-L: http://listserv.brown.edu/archives/cgi-bin/wa?A2=ind0909&L=TEI-L&T=0&F=&S=&P=15221\). Our suggestion would simplify

    <certainty xml:id="foo" target="#foo" match=".." locus="value"/>

    to

    <certainty match=".." locus="value"/>

    removing the need to generate xml:ids for every <certainty> element. Since the document root is easily referred to in an XPath expression (i.e. "/") there is really no need to make it the default context, especially since this removes the ability easily to refer to other nodes in the document from the <certainty> element itself.
    This change would require no schema alterations. The only change needed would be to the text of the guidelines.

    In the thread on TEI-L referenced above, Wendell Piez voiced some objections to the use of @match, based on its similarity to XSLT's @match, which can only contain absolute XPath patterns. The use of a new attribute (perhaps @select, like XSLT @select) was suggested, but since there is already a @select attribute in the att.global.linking module, we would prefer to modify the definition of TEI @match instead. A further note in the guidelines stating that TEI @match is not XSLT @match might be warranted.

     
  • Syd Bauman
    Syd Bauman
    2009-10-16

    Remember to think about how the value of xml:base= (on the current element or any of its ancestors) affects the default context.

     
  • xml:base would affect relative URI's (so @target would potentially be affected, though see http://www.w3.org/TR/xmlbase/ 4.4 on same-document references). I'm not so sure about @match. Would it be affected? I'm not sure XPath patterns are in xml:base's scope....

     
  • Syd Bauman
    Syd Bauman
    2009-10-17

    Yes, a relative @target is relative to the xml:base.

    As for @match, the question as to whether or not it would be affected is exactly the question that needs to be resolved. I'm not suggesting (here and now) that the answer be “yes” or “no”, but rather that Council needs to explicitly decide, and the answer on should be clearly documented in the Guidelines. (If XPath patterns are not in xml:base's scope, then the answer is “no”, of course.)

     
  • I think I would argue that XPaths are outside xml:base's scope, since they aren't URIs. As for @target, URIs like "/otherfile.xml#foo" would be subject to xml:base, but "#foo" would refer to the current document, per the xml:base spec. A @match used in conjunction with @target might point to a node in a different document in the former case, but I think this is fairly straightforward. The point we want to argue for is that the default context should be the current certainty element rather than the current document root. You can already use @target to reset the context, and presumably you could use it with @xml:base to reset it to a node in another document entirely. I think defining the effects of xml:base in the guidelines should be the subject of another feature request.

     
  • Lou Burnard
    Lou Burnard
    2010-01-18

    Two issues here (a) whether or not the interpretation of @match is affected by the value of xml:base and (b) that the default value for @match for be "." rather than "/" (i.e. the current element context, rather than the document root)

    Council did not explicitly discuss the former, but I think it is entirely reasonable to argue that xml:base doesnt affect the interpretation of a match pattern. It did (eventually) discuss the latter, and there was no strong consensus for retaining the current meaning. Some uncertainty however whether, in the absence of a @target, thhe context for @match should be "here" (i.e. the certainty element itself) or its immediate parent.

     
  • BODARD Gabriel
    BODARD Gabriel
    2010-01-18

    I don't think there is actual uncertainty about the context of @match without @target--surely it should be the current element, so that relationships such as parent:: or sibling:: can be used with relation to it.

    (The confusion arises from the use of the expression "parent node" in the original discussion, but this refers to the parent node of the @target attribute, i.e. the certainty element itself. I don't recall there being any disagreement or continued confusion after this was explained at the Council meeting.)

     
  • Just to be clear, we are asking that the note on @match which currently reads "The context for the pattern is the nodeset identified by the value of the @target attribute. If no value is given for @target, the context is the document root element." (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-certainty.html) should read instead:

    "The context for the pattern is the nodeset identified by the value of the @target attribute. If no value is given for @target, the context is the certainty element to which the @match is attached."

    So we'd like the default context to be redefined, not the default value of @match.

     
  • Lou Burnard
    Lou Burnard
    2010-01-19

    I think Wendell's concerns might (maybe) be better addressed by a wording such as

    "The pattern supplied is evaluated against the nodeset identified by the value of the
    @target attribute. If no value is given for @target, tit is evaluated against the
    certainty element to which the @match is attached."

    I'll ask him

    Looking at it again, this whole chapter needs some serious reorganization, or at the least some subheadings.

     
  • BODARD Gabriel
    BODARD Gabriel
    2010-01-19

    That seems fair enough, yes. With the slight modification that we should remove "certainty" from the sentence below, since @match also sits on <precision>.

     
  • Good points both. Context is a loaded word, since it means something very specific in XSLT, which doesn't really apply here. I was forgetting precision. So:

    Date: 2010-01-19 12:19
    Sender: louburnardProject Admin

    I think Wendell's concerns might (maybe) be better addressed by a wording
    such as

    "The pattern supplied is evaluated against the nodeset identified by the
    value of the @target attribute. If no value is given for @target, it is evaluated
    against the element to which the @match is attached.

     
  • Sorry, sourceforge UI seems quite broken. "nobody" in the last comment is me. Instead of copying Lou's message, I meant to say:

    "The pattern supplied is evaluated against the nodeset identified by the
    value of the @target attribute. If no value is given for @target, it is evaluated
    against the element to which the @match is attached."

     
  • Lou Burnard
    Lou Burnard
    2010-02-01

    After much discussion a revision to the text is now being checked by Council, so I am closing this ticket.

     
  • Lou Burnard
    Lou Burnard
    2010-02-01

    • status: open --> closed