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

[Stan Sutton <suttons@xxxxxxxxxx>]

Bill,

Thanks for the response.  (Peri
assured me that you would have something to say on this topic.)  Regarding
the Ant loader, Matt would be the authority, and I should probably let
him respond.  Nevertheless, I'll respond anyway :-)

I think the current Ant loader may be
somewhere between the DOM approach and the SAX approach you used.  Looking
through the code, I get the impression that it started as a DOM parser
but then migrated to a SAX parse.  There are references to DOM but
they've been commented out.  The XMLNode class, which used to wrap
a DOM node, now just stores the information it needs directly and doesn't
use a DOM node.  The XMLLoader used to call a DOM parser utility and
now calls a SAX parser utility.  However, as I read it (and here my
lack of experience may be showing), the SAX parser is used to create an
intermediate representation (an XMLNode tree rather than a DOMNode tree?)
that is then traversed to construct the concern model--this sounds different
from what you describe.

Matt, I hope I haven't misrepresented
your work (or misrepresented it too badly).  As I said before, for
all I know the performance of the Ant loader may be perfectly acceptable
given the relative size and numbers of Ant files we expect to encounter.
 But there are the other XML-based languages to worry about ...

Stan

Bill Harrison/Watson/IBM@IBMUS Sent by: cme-dev-admin@xxxxxxxxxxx 11/02/2004 05:21 PM Please respond to cme-dev

To:        cme-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [cme-dev] Thoughts on rearchitecting the Ant loader (and other XML-artifact loaders)

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 ...

_______________________________________________
cme-dev mailing list
cme-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cme-dev