Re: ANN: ASIS2XML 20041024a

[Simon Wright <simon@pushface.org>]

Martin Krischik <krischik@users.sourceforge.net> writes:

> Simon Wright wrote:
> 
> > ASIS2XML converts a unit's ASIS representation into XML, so as to make
> > it easier to develop transformational tools using (for example) XSLT.
> > 
> > As supplied, it relies on GNAT; the only ASIS-for-GNAT feature it
> > relies on is that Data_Decomposition.Size has been extended to work
> > for Subtype Indications; and that only so that it can work out how
> > many bytes a record component will occupy when streamed (this part is
> > in progress)
> > 
> > Not every ASIS feature is supported yet.
> > 
> > There is no XML Schema as yet (however, the output's structure follows
> > that of ASIS as determined from the Ada specs -- I'm not at all sure
> > this is the Right Thing for an XML representation).
> 
> Well XMI would be cool. All important UML tool can import XMI. Also
> it is a standart.

Where did I say XMI?!!

I can see the attraction of it, not that I'd thought of such a thing,
but it seems to me that a UML model is going to be (ought to be) a
representation of a problem domain at an abstraction level rather
higher than that of an Ada program. If it's at the same level, why not
just write Ada?

  Model------------------>Code-----------+
               ^                         |------->Executable
               |    Support libraries----+
               |
        Translation rules

There are all sorts of things you can say in Ada that have no natural
representation (that I'm aware of, anyway, though I'd be prepared to
be proved wrong) in UML; for example, a generic formal subprogram
parameter.

I'm pretty sure that XMI would allow communication at the syntactic
level but not at the semantic level. After all, to do anything really
helpful with UML you need a profile to say what the symbols (those in
the standard, and your extensions) actually mean.

The sort of thing I had in mind was where

   type Rec is record
      I : Integer;

turns into

    <ordinary_type_declaration>
      <defining_identifier>
        Rec
      </defining_identifier>
      <type_definition>
        <record_type_definition kind="ordinary_trait"/>
        <record_definition>
          <component_declaration>
            <defining_identifier>
              I
            </defining_identifier>
            <component_definition kind="ordinary_trait" size="32">
              <subtype_indication>
                <identifier>
                  Integer
                </identifier>
              </subtype_indication>
            </component_definition>
          </component_declaration>

From comments in the ASIS source pointed out to me elsewhere, the
lines 6-7 are like that because of (asis.ads)

--  The subordinate Trait_Kinds allow Declaration_Kinds and Definition_Kinds
--  to enumerate fewer higher level elements, and be less cluttered by all
--  possible permutations of syntactic possibilities. For example, in the case
--  of a record_type_definition, Definition_Kinds can provide just two literals
--  that differentiate between ordinary record types and tagged record types:

which isn't a good argument for an XML representation (I'm not sure
it's a good argument for an Ada representation, either, but that would
be second-guessing the standard).

-- 
Simon Wright                               100% Ada, no bugs.