Opened 8 years ago
Last modified 3 years ago
#4171 new defect
Schema of the "dumpXMLDAE" output points to dead URL
| Reported by: | Owned by: | somebody | |
|---|---|---|---|
| Priority: | low | Milestone: | |
| Component: | *unknown* | Version: | |
| Keywords: | xml, dae | Cc: | Francesco Casella |
Description
Hello,
The XML schema of the "dumpXMLDAE" output points to http://home.dei.polimi.it/donida/Projects/AutoEdit/Images/DAE.xsd. This address doesn't exist anymore. In fact, the entire personal webpage of Filippo Donida, the coauthor of the 2009 paper which introduces this representation (1) is "not found 404". There is still the homepage of another coauthor (http://home.deib.polimi.it/casella/)
Anyway, I believe it would be safer to put the schema (assuming somebody can find it, perhaps the other coauthors) at a more permanent address. Maybe modelica.org if this representation is standardized enough.
Also, I saw other tickets here about the "XML output from Modelica", but I'm not sure it is the same one as this XML DAE (e.g. issues #4024 and #3857), since those tickets mention a schema defined by JModelica people. Is there a relationship ?
best,
Pierre
(1) An XML Representation of DAE Systems Obtained from Modelica Models, 7th Modelica Conference, 2009 https://www.modelica.org/events/modelica2009/Proceedings/memorystick/pages/papers/0073/0073.pdf
Change History (10)
comment:1 by , 8 years ago
| Cc: | added |
|---|
comment:2 by , 8 years ago
comment:3 by , 8 years ago
| Milestone: | 1.11.0 → 1.12.0 |
|---|
Milestone moved to 1.12.0 due to 1.11.0 already being released.
comment:4 by , 8 years ago
Dear Prof. Casella, thank you very much for taking the time to clarify the history of this XML feature (or this set of features as it becomes clear now).
Now regarding you proposition, I'm in fact not heavily involved in Modelica, just teaching an optional course on it (and as such, I'm doing some self-teaching). In fact I don't fully remember why I was looking at this XMLDAE function. Probably I just wanted to have a look at the final DAE structure before translation to C code, to get some ideas of what is going on "under the hood".
As a simple user, I would recommend to remove this dumpXMLDAE function since it is deprecated (if I understand correctly). This would simplify the scripting API. And if so, this specific issue should be closed as "won't fix".
best,
Pierre
comment:5 by , 7 years ago
| Milestone: | 1.12.0 → 1.13.0 |
|---|
Milestone moved to 1.13.0 due to 1.12.0 already being released.
comment:7 by , 5 years ago
| Milestone: | 1.14.0 → 1.16.0 |
|---|
Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0
comment:9 by , 4 years ago
| Milestone: | 1.17.0 → 1.18.0 |
|---|
Retargeted to 1.18.0 because of 1.17.0 timed release.
Replying to Pierre Haessig <pierre.haessig@…>:
A bit of history first. In 2003, Adrian Pop did some work for XML representation of Modelica source code, see https://www.modelica.org/events/Conference2003/papers/h39_Pop.pdf/at_download/file
In 2008-2009, my PhD student Filippo Donida worked instead on an XML representation of the flattened system. The idea, which is thoroughly discussed in this paper http://www.ep.liu.se/ecp/029/005/, was that there were many interesting things one could do with that, and that you didn't need all the intricacies of Modelica to represent the DAE, while XML would be easily transformed into any target language. Filippo worked on the implementation of the dumpXMLDAE function in OMC, which I understand is still somehow functioning, though I'm not sure it will survive the transition to the new front-end (comments on this point by competent developers are welcome).
The most recent copy of the DAE.xsd file is found here: https://svn.ws.dei.polimi.it/simforge-anonymous/trunk/xml/schemas/DAE.xsd. If you're interested, I would be grateful if you could check if it is still valid, in which case we could store it on the openmodelica.org website and update the dumpXMLDAE output.
A few years later, I sent a master's student, Roberto Parrotto, to Lund University, where he worked with Johan Akesson and the JModelica.org team to develop a more comprehensive approach, using different XML concepts. Roberto actually helped develop the XML schema for the variables description in the FMI standard, and completed it with some more stuff to describe the equations. He implemented this schema in JModelica.org, the work is described in this paper http://www.ep.liu.se/ecp/047/010/ecp4710010.pdf and in this report http://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=8847479&fileOId=8859305. If I remember well, this XML representation was actually used as an intermediate representation for the generation of optimization code.
This new XML representation was later also implemented in OMC as a Susan module, which you activate with --simCodeTarget=XML. So, both JModelica.org and OpenModelica support it.
The idea was to continue that work and further extend it, e.g. by adding discrete variables, events and when statements, possibly standardizing it within the Modelica Association. In 2012 Hilding Elmqvist proposed a grand plan for a unified comprehensive XML schema that could represent Modelica source code and various stages of the model transformation into flat equations and solved equations. The idea was that all these representations had common features, so instead of developing N mutually incompatible schemas, it would have been better if each representation picked the parts of the overall schema that were relevant. The idea was good, but probably way too ambitious: it required substantial effort and resources, which eventually Dassault Systemes did not put on the table, so the whole thing stalled, and later on interest in this topic faded a bit, as all the major proponents got busy with other things.
Today, OMC allows you to fine-tune the kind of transformations that are carried out by the back-end, so one can easily obtain the flat DAE representation that exactly matches you needs. For example, you can decide if you want to apply index reduction or not, if you want to evaluate parameters, solve symbolically some equations, inline function calls, etc.. This works well with the new XML approach, because it runs as a code generation module after the back-end has finished. I understand Filippo's earlier approach is instead less flexible from this point of view, because it was hard-coded on the DAE data structure, at the time Susan had not been developed yet.
If you are interested in all this stuff for your work and willing to put some effort, we could re-start this activity and try to push it forward. I'd be glad to help.