[kepler-dev] Modifying MoML files

[Hogan, D. (GE Energy)]

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.