Submitted By: Susheel Varma


Adddate: 2008-11-07 14:16:37
06/05/07 17:11:22 changed by susheel@dcs.shef.ac.uk  ¶

Lee's initial thoughts on this:

    As far as XML schema are concerned, there are three standards which we
might want to review and consider - DTD, W3C XML Schemas, and RelaxNG (OASIS
standard).

    I would personally avoid DTD, and steer more towards the W3C schemas or
RelaxNG. Both RelaxNG and W3C schemas are more flexible and less ambiguous than
DTD. W3C schemas seems to be better supported by tools and libraries for now,
but RelaxNG is easier to learn and gaining popularity.

    See the Wikipedia article and XML.com article

Delete 06/05/07 17:24:17 changed by susheel@dcs.shef.ac.uk ¶

My personal thoughts on this:

    The specification still explicitly wraps C code within its specification.
Portability will be major issue, when eventually the framework moves onto other
languages and platforms.

    To ensure portability, I feel C code logic must either be represented as
XML tags(similar to the templating system constructs) or a different symbolic
mark-up language must be found. If this can be done, we could use some clever
symbolic language manipulations to do some intelligent stuff.

    Also XML, although being the de-facto standard for data representation, is
not ideal for model specification in terms of its large size, verbosity, and
ease of use.

    A more flexible language could be used for model specification. Standard
parser generators could be used to generate parsers for our new language.

    Having said that, another point to note is that the end users will not be
willing to learn XML or some new language just to generate some code. A
suitable replacement in the form of a GUI that generates the specification
behind-the-scenes must be found.

Delete 06/12/07 14:24:01 changed by susheel@dcs.shef.ac.uk ¶

    * Target Date: July 15th 2007
    * Final Deliverable: Aug 31st 2007 

Delete 03/20/08 23:29:11 changed by susheel@dcs.shef.ac.uk ¶

I think we met the deadline, although the model specification document was not
anywhere near complete. We are also having updates to the specification done as
an ongoing process. eg. the introduction of ADT's, dynamic arrays, Macros,
States(in functions). This must really stop it is hard for someone to code to
the existing Flame framework, let alone a constantly changing one.

Either design it upfront or have a encompassing discussion about why you would
like to add stuff/gunk into the model. This might raise the question why wasn't
it there in the first place. What has brought about this need for change? Can we
get away with using some syntactic sugar? Hey, someone needs to ask them.