#23 Problems with XSLT transformations in complex models

[Jaime Souza]

Dear All,

I am facing some problems to convert the XML to the XHTML of a model with multiple components (Submodels). The XML (attached) seems to be write but the XHTML is almost empty. Maybe it is related to the XSL.

p.s.: I use Python lxml (etree) to produce the XHTML.

Thanks,

Jaime

[ciroki]

Hi Jaime,

It seems it does not work only if you explicitly tranform the .xml into the .html format (i.e. using lxml). The block from the .xsl file below:

<script type="text/x-mathjax-config">
        MathJax.Hub.Config({
            jax: ["input/TeX", "output/HTML-CSS"],
            tex2jax: { inlineMath: [ ['$','$'] ] },
            displayAlign: "left",
            CommonHTML: { linebreaks: { automatic: false}, 
                          preferredFont: null, 
                          mtextFontInherit: true, 
                          styles: { '.MathJax_Display': { "margin": 0 } }
                        },
            "HTML-CSS": { linebreaks: { automatic: false}, 
                          preferredFont: null, 
                          mtextFontInherit: true,
                          styles: { '.MathJax_Display': { "margin": 0 } }
                        },
                   SVG: { linebreaks: { automatic: false}, 
                          preferredFont: null, 
                          mtextFontInherit: true 
                        }
        });
</script>
<script type="text/javascript" async="true" src="https://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"/>

works well if you put the bottom <script> block before the <script type="text/x-mathjax-config"> block. Please try and let me know if it works.<br> I need to check why it works when displaying .xml directly in a browser.</p> <p>Cheers<br> Dragan</p></script>

[Jaime Souza]

Hi Dragan,

I have tried moving the position of the elements as you said, but It didn't solve.

So I changed the XSL, as shown in the attached where I commented my changes.

As I said before my model has an "empty" base model that other Components (using the same nomenclature of the XSL. The variables, parameters and all the stuff are inside these Components. So the XSL I propose is recursive in the Components nodes. Here is the example case with this new XSL (I have to publish this because the my browser security does not permit local XSL and/or CSS):
https://s3-us-west-2.amazonaws.com/jaimenms/daetools/example_02.json.model.xml

p.e.: This MathJax is very powerful. I haven't used it before. It worked fine with almost all my equations except three cases where the name of the model is used together with the name of the variable (example: BC_Plb_P_node_A). The problem is actualy the name of the model (or the component), that I used "". I am not sure hall to escape it as the name of the model can't have special characters.

Thanks,

Jaime

[ciroki]

Hi Jaime,

Yes, it does show all components (sub-models).
However, the idea behind my approach is the following. Models can have many sub-models. What if a model has an array of 100 instances of the same model? Should all of them be displayed? In the approach I chose, only the structure of the top-level model is displayed and only the sub-model types and names shown. The structure of the sub-model can be saved into a separate xml file. This method is better, in my opinion. What is missing now are automatically generated .xml files for all sub-models and adding a link to these files in the section Components. Something like this:

Components
Name     Model                      Description
node_A   Source <source.xml link>   Submodel node_A ...
node_B   Sink <sink.xml link>       Submodel node_B ...
pipe_01  pipe <pipe.xml link>       Submodel pipe_01 ...

This way, the model structure will be much clearer, without unnecessary repeats of model definitions for the same type. I can add this into a new release. What do you think?

Regarding the model/variable names, I think '_' should be automatically replaced with '\', but I will check.

Cheers,
Dragan

[Jaime Souza]

Hi Dragan,

The idea is that a single call to the SaveModelReport() could generate multiple XML (one for the main model and the others for its components). If so, you should consider that the name of the component xml file includes the hierarchy or the tree (like a breadcrumb).

I think it would be great to have it in your new release.

I have another suggestion: to include version control to the XSL and CSS files, to publish your XSL and CSS files in the daetools.com and to point these URL in the XML. It would help the access to the local XML in the Browser without any Security error.

Thanks,

Jaime

[ciroki]

Hi Jaime,

Yes, you're correct. First, the model hierarchy needs to be traversed and all unique model types collected. For instance, if the model M1 contains sub-models SM1 and SM2 and SM2 contains SSM1 sub-model, the generated file names could be:

• M1.xml
• M1.SM1.xml
• M1.SM2.xml
• M1.SM1.SSM1.xml

The version control can be added. I believe what you meant is that .xsl and .css file names include the version, i.e.: dae-tools-1.0.xsl and dae-tools-1.0.css and the .xml reports link the appropriate version. Am I right?

On the other hand, I already had some thought about using the online versions of .xsl and .css files from the DAE Tools website in model reports (they already exist and used by the model reports in the Documentation section). The current approach always uses the .xsl/.css relative to the .xml report file:

1. Local files load the local .xsl and .css files (from the same directory as the .xml file)
2. Online files load the online .xsl and .css files (from the same online directory as the .xml file)
   However, the question here is can the local files link the online .xsl and .css files? The reason: at the time I developed model reports the loading .xsl from a different domain was not allowed in the browser (same-origin security policy).

Using online .xsl/.css files:
Pros

• Model reports are single files only (now one needs to copy both .xml and .xsl/.css files)
• The reports always use the version used to generate them
• Security errors won't exist and loading XSL transformations from a different domain might be allowed (cross-origin resource sharing) but needs to be double-checked

Cons

• To open model report one needs an internet connection to get .xsl/.css files (although that is already required for visualising equations using MathJax)

The new approach will therefore always use online files.
What do you think about the above-mentioned issues?

Cheers,
Dragan

[Jaime Souza]

The version control can be added. I believe what you meant is that .xsl and .css file names include the version, i.e.: dae-tools-1.0.xsl and dae-tools-1.0.css and the .xml reports link the appropriate version. Am I right?
Yes.

The reason: at the time I developed model reports the loading .xsl from a different domain was not allowed in the browser (same-origin security policy).
Yor are correct. It is still not allowed to have xml and xsl in different domains.

Maybe you could create a SaveModelReportHtml() that extends the SaveModelReport() to generate the xhtml (that points to the remote .css).

p.s.: I suggest you copy MathJax to your daetools.com and point the link to your domain, Jjust in case their link changes in a future.

[ciroki]

Great. Thanks.

In general I can generate xhtml files. The main reason for xml files was model serialization: one can load the saved .xml file and regenerate the model (although not fully functional at the moment). An additional benefit is having model reports. If that is not required, the new SaveModelReportHtml function can be used (internally using lxml, but I need to check if lxml can use MathJax to create html or just leave as it is and process equations in a browser).

I can copy MathJax to daetools.com but using MathJax CDN is probably more reliable way to deliver it. Anyway, MathJax is not an issue.

Cheers
Dragan

[Jaime Souza]

Hi

The xml files for model serialization is a great idea. It is a very wise solution. The html will only help the debug (locally).

Tks,
Jaime