Re: [help-GIFT] MRML stuff

[Stephane Marchand-Maillet]

Hi, Steph again (from the tram),
> Yes, and no. I think we are thinking of two kinds of style sheets here. You
> are thinking of creating a whole new framework where you do some kind of more
> or less dynamic binding within libMRML to operations provided by the plugins.
> BTW although this smells like JAVA, you could do this in c++, too, what you
> would have to provide as a plugin programmer, would be a hash from function
> name to function object. This is a cool idea.
> 
> What I was thinking of, was much more simple. I assume that mrml works nicely
> for this 1.0 version, and that some people have code for that written for the
> GIFT. Hmm. Strong assumption. Anyway. What I thought of would be libMRML
> providing a service like: my plugin understands "1.0", the current session is
> in "2.0" so there is a 2->1 stylesheet that makes the plugin think it gets
> (and gives back) 1, while everything else works in 2. This would basically
> mean no additional work, except including an exsisting XSLT into GIFT.
 I fully agree that we should do so as to preseverve people's efforts to
integrate MRML into their framework so that what you propose is very
valid. However, I beleive this will not be reproducible for a long time
as difference between versions will become tricky. So what I propose is
an anticipated way to avoid sacrificing so code later... Two tracks can
be thought of in parallel. Moreover, although not fitting well with the
CVMMlab objectives, I am sure their are some generic research issues
below it that could interest some people (who in turn may be less
interested by the specific aspects of MRML)...
 Further, I still think that defining the stylesheet you propose will
call for the definition of the abstract structure of MRML that I
propose. If some parts are plugin-related, then it would be a very good
time to clear them off the generic specification (or, at least to
identify this). In other words, doing such an effort may allow for
bettering MRML even further...

> >  The way I see this is the fact of defining a meta-language, propably
> > close to an enhanced Schema, allowing to define the stucture (syntax
> > abnd rules) of MRML but also link to some implementation. You would end
> > up with something which looks like:
> >  <mrml-xsd:element name="open-session" method="openMRMLSession"
> > valid-from-version="1.0"/>
> >  <mrml-xsd:method name="openMRMLSession">
> >    <mrml-xsd:implemented-as name="...."/>
> >  </.. >
> 
> This would mean more work, but it would be simply cool. It would be
> interesting to work out, how far you can go with this interpreter pattern.
 Yes...
 
> >  # the methods implemented would be reusable in the case of a MRML
> > syntax change (concepts remains the same)
> 
> OK. The simpler use of stylesheets would accomplish that, too.
 I think our thinking are equivalent....

> >  # This would enforce consistencies between version. The MRML message
> > would start with a attribute (that shoudl anyweay be added). Any
> > subsequent tag not "valid-from" this version onwards would be seen as an
> > error.
> >  # This process will make easier the handling of MRML syntax errors
> > since, in the spec meta-language nothing prevents to specify exceptions.
> >  # last but not least, distribute such a library would ease the job to a
> > lot of people to implement MRML.
> 
> Yes, and no :-) . While I think that it would surely be helpful within
> libMRML, for attracting plugin writers I think the danger is a bit to make
> things too beautifully. I find what I have seen of JAVA DOM very beautiful,
> but I would be interested to know how many people within this list use or
> have used it to its full extent. This was the main observation leading to the
> "people get some XML tree and extract what they need"-architecture, as it is
> used in GIFT today. However, as the crowd overwhelming us with external
> plugins is not so huge, it might be time to try something different.
 You are right and this is somethiong that we should keep in mind so as
to still be minimalistic...

> At the same time, with a framework that is as flexible as what you propose,
> one should surely be able to mimick the olde behaviour.
 Yep...

 This makes the TODO list and the list of open issues quite long. I may
think of adding an "Open issues" or "Suggestions" page on the site (what
do you think?). In fact, that is what was hidden behind version 2.0
specifications :=)  
 Cheers,
Steph


-- 
Stephane Marchand-Maillet, PhD
Computer Vision and Multimedia Laboratory, Universite de Geneve
24 Rue du General-Dufour - 1211 Geneva 4 - Switzerland
Tel: +41 (0)22 705 7631 / +41 (0)22 705 7660
Fax: +41 (0)22 705 7780 
Email: address@hidden
URL: http://viper.unige.ch/~marchand
     http://viper.unige.ch/
     http://www.benchathlon.net/
     http://www.mrml.net/