Christopher Brooks wrote: > > On 4/10/12 10:02 AM, Hogan, D. (GE Energy) wrote: > > What's the best way to modify MoML inside of kar files? Should I > > use ptolemy.moml.MoMLParser, some other class in Kepler, standard > > tools (XSLT/DOM) or something else? > > Unfortunately, MoML is not well structured xml. This is because of > the <configure> tag. There is something in either the kepler email > archives or the ptolemy-hackers archives about this.
I looked through the archive and hopefully I capture the problem here. It sounds like MoML is well-formed XML but not valid with respect to its DTD. The problem is that <configure> is used for foreign XML (e.g. PlotML) that may have its own DTD/Schema that it conforms to. The current DTD doesn't capture this requirement of ignoring the structure of <configure> besides making sure it is well-formed XML. It was mentioned that the ANY keyword in DTD may work. It would be possible to use XML Schema because xs:any is designed for this situation. It was deemed too slow and/or not worth the effort at the time to make the change. http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/2010-January/0 01247.html http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/2010-January/0 01248.html http://lists.nceas.ucsb.edu/kepler/pipermail/kepler-users/2010-January/0 01249.html http://ptolemy.eecs.berkeley.edu/ptolemyII/ptIIfaq.htm I don't think the keyword ANY will help you in a DTD. The ANY keyword allows for "content (after replacing any entity references with their replacement text) consists of character data, CDATA sections, comments, PIs and child elements whose types have been declared." Since the child element types have to be declared, it doesn't allow for arbitrary well-formed XML. If you must use a DTD, I think your only option may be wrapping <configure> in a CDATA. That's a change to the MoML document though and it may break other things. http://www.w3.org/TR/REC-xml/#sec-logical-struct XML Schema's xs:any is a true wildcard which can allow for any well-formed XML when you use the attribute processContents="lax". Could you use a XML Schema instead of a DTD for MoML? It would allow you to validate without changing the MoML document. http://www.w3.org/TR/xmlschema-1/#Wildcards http://www.w3.org/TR/2006/WD-xmlschema-guide2versioning-20060928/#wildca rd > I'm not sure I totally understand your question, but are you saying > that the MoML files included in the Kepler .kar files change when the > Kepler-specific BackwardCompatibility filter is run on them? I was all set to use filters similar to how Kepler uses them. However, when I ran Kepler's BackwardCompatibility filter against a Kepler generated MoML, I had many changes. I noticed blank lines removed, indenting differences, attribute order differences, element order differences (swapping the order of input and output seemed to occur a lot) and the entire relation section was moved to a different location in the file. Most of those changes would be invisible to a XML aware diff, but there were so many that I wasn't sure if I was going down the right path. In another file, I noticed that the original MoML had duplicate isMultiport and datatype properties. The filter removed it, but why was it there? Unfortunately, this was one of our workflows so I can't distribute it. Here's the section of the diff which shows the duplicates removed after running through MoMLParser. This port was created through the GUI because I don't have any actors with a port named 'port3'. @@ -230,8 +219,6 @@ </port> <port name="port3" class="ptolemy.actor.TypedIOPort"> <property name="output"/> - <property name="dataType" value="unknown" class="ptolemy.kernel.util.StringAttribute"/> - <property name="isMultiport" value="false" class="ptolemy.kernel.util.StringAttribute"/> <property name="dataType" class="ptolemy.kernel.util.StringAttribute" value="unknown"> </property> <property name="isMultiport" class="ptolemy.kernel.util.StringAttribute" value="false"> My goal was to run diff on the output but even with --ignore-all-space, there were lots of changes. I didn't expect so many changes when I used the default filters. > In Ptolemy II, we don't run the BackwardCompatibility filter on all > the files before a release. In other words - the ptII tree includes > files that would be different if the BackwardCompatibility filter was > run on them. We partly do this so that we can test the filters. > Another reason is so that we don't have arbitrary changes in the > change log. Ok. I think my options are to either use a XML diff tool or create a hook to format MoML in a predictable way. I think it is best to edit the file with MoMLParser. _______________________________________________ Kepler-dev mailing list [email protected] http://lists.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
