[kepler-dev] Modifying MoML files

[Christopher Brooks]

Thanks for the analysis of the well-formed XML issue.

Without an example, there is not much I can say about the duplicate
datatype and isMultiport properties.
One possibility is that the default value for datatype is "unknown"
and for isMultiport is "false", so MoMLParser is probably not emitting
MoML for the default values.

_Christopher

On 4/11/12 8:28 AM, Hogan, D. (GE Energy) wrote:
> 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.
>

-- 
Christopher Brooks, PMP                       University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841                                (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 cell: 707.332.0670