Implementation of notation tags in the renderer output

[clange]

Notation tags in the output of the renderer should point from the XML elements that the renderer created to the renderings that were responsible for this. That makes it easiest for interactive tools (JOBAD, editors) to go from the symbol under the cursor to the rendering that was used.

As the rendering element in a notation definition never has more than one PMML child, Michael suggested to add this information to that element, by introducing a special attribute, as we do for elision. (Why not call it "ec" for "extensional context" -- @Christine, any comments?) Imagine a rendering like

<rendering context="..." xml:id="nice">
  <mrow>
    <render name="arg1"/>
    <mo>$$$</mo>
    <render name="arg2"/>
  </mrow>
</rendering>

Then, the PMML output generated from applying this rendering should look something like:

<mrow ec="some/url#nice">
  <!-- recursively rendered first argument -->
  <mo>$$$</mo>
  <!-- recursively rendered second argument -->
</mrow>

If there are no objections against this ticket, it would override #149, concerning the notation tags in the output.

[cmueller]

Yeah, why not. Looks good to me. I assume that the ec-value is a list that includes pointers to all renderings that have been used?

[clange]

Replying to cmueller:

Yeah, why not. Looks good to me. I assume that the ec-value is a list that includes pointers to all renderings that have been used?

Ah, no, the idea actually was to link exactly to one rendering, i.e. the one that was used for rendering this symbol (and not to the ones used for subterms). Otherwise we'd again lose the close tie of the notation tag to the symbol. Let me give a complete example to make this clearer: Consider this formula with two different renderings for the "times" operator:

<mrow ec="url/of/my-rendering-of-times-as-dot">
  <mrow ec="url/of/rendering-of-times-as-invisible">
    <mn>3</mn>
    <mo>&InvisibleTimes;</mo>
    <mi>x</mi>
  </mrow>
  <mo>·</mo>
  <mn>100</mn>
</mrow>

Of course, in the implementation we should put the ec into some special namespace, as we have done for elevel and egroup.

[dmisev]

Isn't it better if we make ec a list of URIs, where the first points to the used rendering, and the others to the alternative renderings?

[cmueller]

Replying to clange:

Replying to cmueller:

Yeah, why not. Looks good to me. I assume that the ec-value is a list that includes pointers to all renderings that have been used?

Ah, no, the idea actually was to link exactly to one rendering, i.e. the one that was used for rendering this symbol (and not to the ones used for subterms). Otherwise we'd again lose the close tie of the notation tag to the symbol.

Okay, make sense. I agree.

Replying to dmisev: @Dimitar: Sounds interesting, but I am wondering how we can maintain these lists. For example consider SWiM, people can continuously add alternative renderings. And keeping the list up-to-date would require to update all math-objects in SWiM that are effected. Also, we'd really need a notion of equality on rendering side then (ticket:181)

[dmisev]

@Christine: yes, you're right about that. I might be wrong here, but in the use cases Christoph pointed in #178:

• SWiM would use the first URI to enable editing of the used rendering.
• JOBAD would use the others to show the possible alternative renderings. How else would this case be possible?

[clange]

@Dimitar, good idea about putting the whole list into the @ec attribute. However, @Christine, you're right that this doesn't work in a SWiM-like setting where rendered documents would stay in the cache, while users would be able to add/remove renderings in the meantime. And of course we really don't want to re-render a document that uses rendering R1 for symbol S whenever some author adds another rendering R2, R3, ... for S.

But for other applications I think it could make sense. Maybe let's have it optionally, if it isn't too much work.

[dmisev]

To attach the used renderings in the renderings process to the math objects via @ec use --rendering-info. Use --prototype-info to include references to the used prototypes during the rendering. Note that this will only work if the renderings/prototypes have xml:id specified.

If you use both --prototype-info and --rendering-info the output will be of the form ec="renderings | prototypes"

[clange]

I'd like to reopen this for discussion. (I thought reopening would be most appropriate, so that we can easily refer to previous comments.) Thanks in advance for any constructive feedback.

In my thesis, I'm currently specifying the markup that will be needed to enable for interactive notation selection, and I would like to get that right. All of you, particularly Dimitar, don't panic -- this will not be implemented soon, unless we get additional manpower beyond the next JOBAD developer assistant. Complete%20Code%20Revision The to-do list of urgent JOBAD tasks is already pretty packed, and notation selection would only be the first new JOBAD service to be implemented after that cleanup.

Some first remarks:

@ec Syntax

The ec="renderings | prototypes" syntax looks wrong to me. (Sorry, Dimitar, that I didn't complain earlier.) At least something is inconsistent. The help says:

  --rendering-info    specify the used rendering for rendering an object
  --prototype-info    specify the used prototype for rendering an object

So it's a single prototype and a single rendering, right? I recall that we earlier said something about listing the rendering/prototype that was used first, and then listing the available alternatives, at least for the renderings. My argument against that has always been that the server can also tell us the alternatives. On the other hand, that would require one more request to the server.

Now if I get the help text right, and judging from my experiments, I think we have the following cases:

1. only --prototype-info specified: ec="prototype-URL"
2. only --rendering-info specified: ec="rendering-URL" -- how to distinguish from case (1) without asking the server? (The server would know whether the URL resolves to a prototype, sure, but still…)
3. both specified: ec="rendering-URL | prototype-URL" -- quite a nonstandard syntax. If we really only put one rendering and one prototype, ec="rendering prototype" would be just as informative and easier to process. Or actually it might make sense to invent a markup that does not put the link to the rendering and the link to the prototype into the same attribute, as they are two different things, and @ec was originally invented for renderings (or for any container of renderings).

Recall that both the reference to the rendering and the reference to the prototype may be needed. The reference to the rendering is clearly needed for notation selection. About the reference to the prototype I'm no longer so sure. I thought that it may be needed for editing notations, but

1. that will not be implemented soon, so we can't really tell how it will eventually work
2. when do we have multiple prototypes per rendering? So far only for CMML vs. OpenMath? matching, but
   1. JOMDoc has never really been tested with CMML. (I suppose it doesn't really work, at least in the OpenMath? wiki most CMML notations are broken.)
   2. if we preserve the original content markup language in the parallel markup, we know anyway whether the content markup was CMML or OpenMath?.

Strict markup?

See also  omdoc:ticket:1556 -- @ec is our custom addition, which to me looks like pragmatic syntax, so we also started a discussion about the corresponding strict syntax.

Maybe put this information into the content markup altogether?

Now that I got more familiar with OMATTR, I'm again thinking of putting those links to the renderings into the content markup. In order to enable a workable notation selection (and many other JOBAD services), we need parallel markup anyway. And in JOBAD we already have the infrastructure for looking up information in the content markup, once we know what presentation markup the user has selected.

@Michael, concerning comment:ticket:149:20 -- do you remember what you said back then? How did you justify that those links should go into the presentation markup and not into the content markup?

[dmisev]

@ec Syntax

the help is wrong sorry about that, it's as we have specified - first the used prototype/rendering, and then the rest that have been collected. Check TagCollectorTest?, you'll find some examples there.

[clange]

Replying to dmisev:

@ec Syntax

the help is wrong sorry about that, it's as we have specified - first the used prototype/rendering, and then the rest that have been collected. Check TagCollectorTest?, you'll find some examples there.

Ah, OK, thanks for your quick reaction! Yes, that would be the only thing to fix immediately. The rest is for discussion. As no software support for this markup (selection, editing) has been implemented so far, and probably won't soon, it would be wrong if I complained too much.

[clange]

Replying to clange:

I recall that we earlier said something about listing the rendering/prototype that was used first, and then listing the available alternatives, at least for the renderings.

Right, according to the test case Dimitar pointed me to, this is what's implemented.

My argument against that has always been that the server can also tell us the alternatives. On the other hand, that would require one more request to the server.

That given, I would like to restart the discussion once more. From a JOBAD point of view, just knowing the URI of an alternative rendering is not enough. The user doesn't want to see URIs in a notation selection menu, but descriptive labels. For me, this has two implications:

• we don't need all alternative URIs in the markup. The server would have to be consulted anyway to obtain the labels. (Or we might consider putting the labels into the markup as well to save that roundtrip to the server, but on the other hand that would bloat the document, particularly if the user never switches a notation.)
• inside the notation definitions, we need markup for the labels. We have that (metadata, maybe dc:description), but those elements have to be allowed inside <rendering/>.