egXML needs a way to highlight renditional aspects in the example

[lb42]

" In a TEI context use of the rend attribute in the TEI namespace, as opposed to the TEI Examples namespace, enables recording of rendition information."

What exactly does this mean? TEI attributes are not in any namespace, so I don't see how you can specify one. The example following this text doesn't help, since it doesnt show any namespaces at all. (And it has an error

<item>The <att>rend</att> attribute in the TEI namespace can be used 
for recording how parts of the example was rendered.</item>

should read "... were rendered" I assume.

[martindholmes]

I had no idea this was in the Guidelines. It makes no sense whatsoever. You could specify a namespace if you want to (putting the rend attribute explicitly in the examples namespace) by using a prefix, but why? I wonder if there's something specific about the way the Stylesheets handle egXMLs which is based on the rend att?

[jamescummings]

I remember this. It was to enable rendering of particular bits of egxml. For example making the element you were taking about in the middle of a larger worked example display as bold. Or other rendition things like that. But also because the xml example might have rendering in the source you want to preserve. All the elements in the egxml are in the examples namespace. I think the idea was that putting rend into the tei namespace (since tei attributes are in the null namespace).

[lb42]

@jamescummings your last sentence is unusually gnomic. Did something drop off?

[sydb]

@jamescummings to investigate what the current stylesheets do with @tei:rend, and what mechanism, if any, they support for highlighting a portion of an example.

[jamescummings]

I investigated this and although I have memories and emails with Sebastian about it working, none of that seems to be in the current Stylesheets. It might have been in a different profile. Or he removed it later. So I've investigated and current stylesheets do nothing.

The question is I guess, whether we should enable some mechanism like this in the stylesheets. The idea is that you have an egXML in some TEI document that is making a point about a particular element and you want to make that particular element (say) bold to highlight it in your output. If not something like this, does someone have a suggestion as to how properly to format particular aspects of egXML content? My assumption is that the use-case is clear enough and completely reasonable: You are showing examples of XML and want to highlight one or other bit in some way. That seems reasonable and pedagogically useful to me. Is there a better way to address and record formatting of particular parts of an egXML?

[jamescummings]

Removing Status: Go since I've done the investigation, as above. I've commented out the misleading prose in the egXML spec file for now. My memory must have been as a local customisation. So my questions are:

1. Should the TEI Guidelines recommend a method of recording rendition information about egXML content?
2. If so, what should that mechanism or mechanisms be? It needs to be something general but flexible, is use of @rendition attribute suitable? How does one record formatting of particular lines of code, individual elements, individual attributes and/or values, or element contents?
3. Should the TEIC Stylesheets use whatever solution we recommend? It is potentially useful in the Guidelines to be able to highlight the element(s) being discussed in the the prose around an egXML.

[sydb]

1. Rendition information in general, or just the “this is the element I’m showing you here” case?

Some thoughts jump to mind:

We sort of already have a mechanism for the former, maybe. What would <rendition selector="teix|egXML teix|persName">font-weight:bold;</rendition> mean? (Surely not “in my original, the example <persName>s were bold” :-) But, of course, that indicates all egXML//persName should be bold, which does not address the latter case. (Which I will call the “demo” case.) What does

        <rendition xml:id="duck" selector="teix|egXML teix|persName">font-weight:bold;</rendition>
        <!-- ... -->
        <teix:egXML rendition="#duck">
           <teix:p>Hi <teix:persName>James</teix:persName>!</teix:p>
        </teix:egXML>

mean?

Another thought is that, for the demo case, it would be nicer to be able to use XPath directly on the <egXML> in question:

        <teix:egXML highlight="teix:p/teix:persName/@ref">
          <teix:p>Hi <teix:persName ref="#JC">James</teix:persName>!</teix:p>
        </teix:egXML>

indicates (as a hint to the processor, of course, not a requirement) that only the @ref should be highlighted. Problem is this means a processor has to be able to do XPath scrubbing, which could be a royal pain. One reason to prefer this mechanism is that it avoids the “rendition is about the source, except when there is none” conundrum.
Another problem is that although XPath gives us an excellent way to pick out which particular elements, attributes, comments, processing instructions, or text nodes to highlight, we don’t have a good way to say “hightlight just the tags of the <persName>, not the content”, or “highlight only the attribute name, not the value”, etc.

Another way of handling this whole problem, which I raised a decade or so ago, is to allow <tei:hi> as a descendant of <teix:egXML>. It has the advantages of being very clear and very easy, but the disadvantages of being very inflexible and very imprecise.

[jamescummings]

Hi @sydb,

If I summarise your suggestions they are basically
a) rendition element
b) XPath
c) embedded hi
if I add to that:
d) embedded namespaced @rend

a) As you note this is sort of saying that all persNames in egXML should be bold, when really we want just one in this particular example, or indeed say its ref attribute. Also there is the fact that rendition is about the source document, and patently really people would be using this for creating new teaching materials and say the Guidelines themselves
b) I like using XPath because then I could refer to almost any part (presumably one could specify just the value of the ref attribute as well with /text() or something else) but has all the problems you noted.
c) I don't like embedded hi except that it works on a well-formed element fragment level rather than just an attribute or its value, etc. It isn't flexible enough.
d) Similarly the original proposed use of rend attribute has the same problem except by magic words understood by some mythical processing 'refAttValue-Bold' or whatever.

Of all of these I like b the best because it gives flexibility. but think it is the wrong way round. What about something-like-rendition but with a context attribute that enables you to give an xpath to what it applies? (Or I suppose the highlight attribute on egXML you suggest but to use it you are required to also point to a rendition-like element giving how it is highlighted. After all, we just don't want them to be bold, but in one example this one bold, the other underlined, and another one shaded with a light blue background... or something.

[sydb]

OK. So, based on what I think you’re thinking I’m now thinking of something like a new @renditionMatch attribute whose value is an XSLT pattern (i.e., the kind of thing that goes in an xsl:template/@match, not an XPath expression which goes on an xsl:apply-templates/@select — although I do not know how to constrain the value properly in a schema) which says, in effect “only those nodes matching this pattern, with this <egXML> as the context node, get the highlighting found in whatever @rendition points to.”

I like it because it is very powerful (renditionMatch="tei:name|tei:persName|tei:rs"), very precise (renditionMatch="child::tei:ref[3]/@target/text()"), and very flexible (renditionMatch="processing-instruction()|comment() except comment()[1]). What I don’t like:

• Only deals with 1 style. What if I want the comments in blue, the naming elements in bold, and the metrical lines in italics?
• Implementation is likely to be painful.
• Need to be careful to only use value of @renditionMatch as a pattern, because evaluating it as an expression is a security problem. (An XPath expression can suck in a document() and cause problems, or maybe even be hacked by injection.)
• May as well be global, no? Wouldn’t it be nice to say <p rendition="#startQuoteMark" renditionMatch="tei:lb[ancestor::tei:quote]">?
• And, most importantly to me, I do not have any way to say “highlight the tags but not the content”. That (to me) is one of the main use cases, and also why I’m not so fond of the <tei:hi> solution.

Since I want to be able to highlight sub-units of the XSLT document model nodes (e.g. delimiters, pseudo-attributes, and most importantly tags), an XSLT solution is quite difficult to come by.

[jamescummings]

Hi @sydb,

I agree that this would be powerful and flexible, but has the problems you mention. So we're agreed that it would be good to be able to highlight arbitrary portions of egXML elements and these are well-described by an XPath pattern. Instead of a renditionMatch attribute I was thinking one needs a new grouping element which then allows zero-or-more renditionMatch (or whatever) elements to address multiple parts of their sibling egXML. Perhaps exemplum could be repurposed for this to contain an egXML and a series of these new elements that link an XPath with a particular rendition id.

Just thinking out loud...

[ebeshero]

Council likes the idea, but probably doesn't have time to work on this for a while. Low priority. Note: we don't know a good mechanism to implement the range of highlighting we envision yet. Suggestion c) above is probably the easiest to implement.

[jamescummings]

c.f. #1928 may be a duplicate of this. While both are low priority we certainly need the ability to mark arbitrary string-lengths inside egXML, but most often this would be known XML parts. A combination of standoff xpointer and standoff byte-offset might be the ideal approach. See that ticket.

[martinascholger]

F2F Council (with guest @jamescummings) is generally in favour of the idea and decided that he will come up with a proposal.

[martinascholger]

ping @jamescummings