Re: Re: SIDE NOTE: CIL Schema

On Tue, Jan 18, 2005 at 02:49:54AM -0800, Alexander Genaud wrote:
> Martin, it seems to me that you intend MLML to be an
> intermediate language between any two tokenized (plain text) or
> XML languages. Such as: o:XML --> MLML --> Java. On the other
> hand, the philosophy behind SrcML seems to be Tool --> SrcML -->
> Java. Would you agree (at least superficially) with that?

The philosophy behind SrcML is not geared towards web-based deployment
as much as o:XML seems to be. And the chain you specified is just one
of the possibilities. The idea behind SrcML is rather to replace 
plain-text source code with a XML based format (in the loooong run) 
and work on that format then. So right now the chain has to start like
some language/Java --> SrcML
whereas it should actually start at SrcML. However many existing
software has of course not been written in SrcML and needs to be
converted to SrcML. So there is definitely a need for this conversion,
but it is not really part of the philosophy of SrcML.

Also the end of the chain with SrcML --> Java is only there to be 
able to work with it at this early stage. F.ex. if you want to get 
some executable program the by far easier way is to convert SrcML 
to Java and use any existing Java compiler instead of writing a 
compiler working directly with SrcML. (Which will be especially
difficult regarding that multiple languages will be convertable to
SrcML)

To summarize the philosophy behind SrcML looks kind of like this:
(Java -->) SrcML --> Tool* --> SrcML (--> Java)
                      |
                      \--> all kinds of 'data' output

When it comes to the development of software the major difference
between SrcML and o:XML as far as I can see is the general idea that
Martin intends developers to write their code in o:XML, whereas I
consider the XML source code as a backend format one manipulates
through tools and does not have to interact with directly.

So much from the SrcML point of view. Feel free to ask if there's
something I left out or explained unsatisfyingly.

With kind regards,
-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

Quality has to be caused, not controlled. (Philip Crosby)