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
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That seems fair enough, yes. With the slight modification that we should remove "certainty" from the sentence below, since @match also sits on <precision>.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
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....
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.
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.
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.
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.
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."
After much discussion a revision to the text is now being checked by Council, so I am closing this ticket.