{5} Assigned, Active Tickets by Owner (Full Description) (15 matches)

For debugging and user evaluations we need a web service that logs all interactions the user makes with other services accessible from a document. This could use a similar knowledge representation as the "saved state" of a document (cf. #284).

I can imagine two steps towards a solution:

1. hard-coding conditional logging code into all modules under our control
2. learning about aspect-oriented programming, implementing a "logging aspect" and decorating all relevant methods with it

At least all actions should have logging code like

if (logging_enabled) {
  log_service.log(this /* the action */,
                  selection /* what's selected or clicked in the document */,
                  rest /* anything else of interest */)
}

That method should then send the selected presentation markup and the corresponding content markup to the server for logging.

I want to keep track of the things that are needed for JOBAD 2.0.

I suggest the main literature and documentation about what needs to be done for JOBAD to scale is here:  http://addyosmani.com/blog/large-scale-jquery/

Starting from this, I can re-design JOBAD to scale for the Planetary system and be as independent and configurable as possible.

Design goal: A JOBAD-enabled document should only require the following additional lines:

<script type="text/javascript" src=".../jobad.js"/>
<script type="text/javascript">
  jobad.load("definitionLookup");
  // ^^^^^^^ not yet sure what the actual syntax will be, just an example
  jobad.load("contextMenu");
</script>

Therefore, jobad.js has to load all JS and CSS files of the required toolkits (e.g. jQuery, GWT, etc.) automatically. Maybe this can be done in such a way that the toolkit-provided (cf. #546) JavaScript module that manages module dependencies (cf. #411) is loaded first, and for the rest of the module loading this dependency mechanism is used.

We need templates for <meta>, <link>, and <resource>. They should do something sensible with these elements.

If we run linktest on  https://svn.omdoc.org/repos/omdoc/trunk/examples/logics/pl0.omdoc, we get

WARN : redundant import /Users/kohlhase/vc/svn/omdoc.org/omdoc/trunk/examples/logics/qbf.omdoc#qbf
 in theory /Users/kohlhase/vc/svn/omdoc.org/omdoc/trunk/examples/logics/pl0.omdoc#and-prop.thy
----------------------------------------------------
 WARN : redundant import /Users/kohlhase/vc/svn/omdoc.org/omdoc/trunk/examples/logics/qbf.omdoc#qbf
 in theory /Users/kohlhase/vc/svn/omdoc.org/omdoc/trunk/examples/logics/pl0.omdoc#xor-prop.thy
----------------------------------------------------
 WARN : redundant import /Users/kohlhase/vc/svn/omdoc.org/omdoc/trunk/examples/logics/qbf.omdoc#qbf
 in theory /Users/kohlhase/vc/svn/omdoc.org/omdoc/trunk/examples/logics/pl0.omdoc#tnd.thy
----------------------------------------------------
 WARN : redundant import /Users/kohlhase/vc/svn/omdoc.org/omdoc/trunk/examples/logics/qbf.omdoc#qbf
 in theory /Users/kohlhase/vc/svn/omdoc.org/omdoc/trunk/examples/logics/pl0.omdoc#or-prop.thy
----------------------------------------------------
 WARN : redundant import /Users/kohlhase/vc/svn/omdoc.org/omdoc/trunk/examples/logics/qbf.omdoc#qbf
 in theory /Users/kohlhase/vc/svn/omdoc.org/omdoc/trunk/examples/logics/pl0.omdoc#implies-prop.thy

but as far as I can tell, they are legitimate; indeed, if I take the import statements out, linktest will complain about missing imports.

This ticket is triggered by an application where we are not using JOMDoc from Planetary, but for sTeX-generated OMDoc. <omdoc:term and om:OMS should carry hyperlinks (in Planetary this is done by JOBAD, but as said above, we should also have some functionality statically). Therefore I would like to have an option in jomdoc to add hyperlinks in these.

Currently <omdoc:term cd="foo" name="bar">sdfsdf</omdoc:term> does not do that. You can see this at  https://tnt.kwarc.info/tntbase/stc/XHTMLBasicBrowser/slides/graphs-trees/en/bbt-size.omdoc (the blue word "balanced" in the middle), which creates.

<span omdoc:cd="balanced-binary-trees"
      omdoc:name="balanced-binary-tree"
      class="omdoc-term"
      about="http://linkeddata.tntbase.org/slides/graphs-trees/en/bbt-size#size-lemma-pf.derive2.method2.proof2.derive4.CMP1.term2">
 balanced
</span>

This should be wrapped in a <a href=""> elements, so that have a static hyperlink. The URL can be computed by looking up (and recursively computing the relative URIs) the module in the <omdoc:imports>.

The case for om:OMS is similar, there we should add the xlink:href attributes and/or the new href attribute from MathML3 for linking on the respective MathML.

This should be no big problem to generate (we should be able to remove these by an option that we can specify for Planteary).

@Dimitar, can you give an estimation?

Please revise the following text from the journal paper, do we support all attributes in JOMDoc?  https://svn.omdoc.org/repos/jomdoc/doc/blue/mkm-journal/ntn-xml.tex

The tag element can be stored outside the document (e.g. in a user model or separate file). The type attribute provides the type of the tag, i.e. notation for all notation tags. The xref attribute points to the referenced notation, i.e., the rendering element of a notation specification. Its value is constructed from the xml:id of the document, notation specification, and its rendering child. The remaining attributes specify the condition, which are used to prioritize tags: The weight attribute represents the relevance of the tag. The context attribute associates context-parameters with the notation tag. The object attribute references the mathematical objects, to which the notation specification has been and preferably should be applied to. If the object-reference of a notation tag is set, the notation tag is only valid for the referenced objects. Vice versa, if the object-reference is missing, the notation tag is valid for any object that matches its pattern. The notation tag have an optional attribute owner, which e.g. relate a tags to the respective author of a document. For simplicity, we do not display the latter attribute.

Do you agree with this specification?

There may be CSS style sheets associated with the source document via the stylesheet processing instruction (cssPI) in the XML prologue. See  the W3C recommendation for details.

It would be very good, if we could use this mechanism to add style to the presented counterpart of the OMDoc document that has this cssPI. That way the author can convey styling intuitions about his/her document. To get this, the cssPI must be copied into the result document whereever appliccable.

Note that there is a problem here, so maybe this is not the best way of doing this. I would like feedback here.