Re: [cme-dev] Thoughts on rearchitecting the Ant loader (and other XML-a

[Bill Harrison <harrisn@xxxxxxxxxx>]

I'd like to make a note about one item discussed in Stan's note. He wrote:

"Regarding the Ant loader (and XML/parser-styled loaders):  The Ant loader
has a reasonable architecture that seems systematic and appropriate for an
XML-based language.  Thus there seems to be no solely architectural reason
to replace it.  Ant loading involves parsing the input (Ant/XML) file and
then visiting the nodes in the parsed structure and creating concern-model
elements for them.  It does not seem (as far as I know) that the elements
in the input file, or in the structure parsed from it, are natively
addressable by name, although you can navigate up and down in the parsed
structure (i.e., DOM or XML tree).  So the parser-style loader seems
naturally suited to loading a whole artifact model top-down, but not
naturally suited to loading arbitrary elements from the middle of a
model.  Also, there seems to be less incentive (and perhaps less sense) to
having specialized types of loaders for specialized types of elements,
e.g., one for top-level Ant files, one for Ant targets, one for Ant tasks,
etc.  This strikes me as so because a) all types of Ant artifact are
represented as elements in an XML file (i.e., they're all made out of the
same stuff), and b) I don't think it will be likely that people will want
to load, say, Ant tasks outside of the loading of an Ant file, so there
would be little call for an Ant-task loader that could be reused in various
other sorts of loader.  (Although I could be wrong about any of this.) "

I make the following observation:

There is another alternative for XML-style loaders. It appears from this
description that the ANT  loader uses a "DOM parser" approach rather than a
"SAX parser" approach. Both are made available by the same Apache code. The
UML/XMI parser I wrote a few years ago for the UML implementation of CAT
was a "SAX parser" style of processor, which had the significant
performance advantage of not creating a full DOM tree, especially for
elements that were not of interest to the model. Instead it created the
equivalent of the concern-model elements "on-the-fly" directly from the
parsing events. This approach was simplified by adopting a framework of
response to SAX events that was particularly suited to registering handlers
for elements or subsets of elements of interest, rather than a single
handler; and that ran a stack for the components of elements with multiple
sub-pieces. So perhaps that would be a different approach to ANT-loader
performance problems, such as they are.

This does not address Stan's point about the structural nature of ANT
information hat tends to reside within a single artifact vs. named
information that may be accessible from outside the artifact in which it
resides.

                          - Bill

http://www.research.ibm.com/people/h/harrisn/

derevaun seraun ...