Re: [help-GIFT] MRML stuff

[Stephane Marchand-Maillet]

> > > I'm in Thailand now, already complete my master degree (thanks for
> > > David).
 Yes, congratulations! I thought of that and was so eager to write the
rest that I eventually skipped this sorry...
> Congrats!

> >  I see this as an extendable library.
> What is "this"?
This is "how to add new handling code for the extension in GIFT too"
(from the original message). 

> > We discussed this with Wolfgang
> > sometimes ago and I'll sketch something...
> I think stylesheets are what gives us flexibility here. Somehow I see future
> libMRML as quite similar to what it is now plus a stylesheet processor that
> translates between differring versions of MRML where applicable. This would
> give us a maximum of extensibility.

 Ok, here is the mainline of my twisted thinking :-)
 * I thought of stylesheets to convert from versions to versions.
However, this would mean having a base version. DO we take the curent as
base? I do not think this is wise. Rather we should "abstract" MRML
somehow and have some way of extending this abstraction. If you think
about it, the process of defining a stylesheet anyway forces you to do
so...
 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="...."/>
 </.. >
 The library would therefore read this spec file, understand what are
the valid tags and their embedding but also know what to do with them.
 This has a number of advantages including:
 # the methods implemented would be reusable in the case of a MRML
syntax change (concepts remains the same)
 # 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.
One caveat: Is this manageable in all languages (eg PHP?) 

OK, another:  who is implementing that?
(http://vision.unige.ch/Teaching/proposeddiploma.html :-; )

> > > I quite agree with him. GIFT is a test-bed for MRML, hence, MRML should
> > > have its own space, or even community.
> >
> >  Thanks :-)
> 
> Good. Everyone agrees with that?
> 
> > > I didn't look at xml:lang yet, but the recent proposal by Wolfgang is
> > > looked very good for me.
> 
> Thanks.
> 
> >  I agree that whatever is simpler is better. However, people get used to
> > some "style". I was saying that some people have had some thoughts on
> > that and rather that reinventing something that may eventually converge
> > to their solutions, we should not divert for them too much.....
> 
> I see this point. However, the focus is quite different. The xml:lang tells
> the processor what language to expect within the tag that contains the
> xml:lang attribute. You can have several tags with the same content in
> different languages present in the same text. The processor will then choose
> the appropriate language. This is quite similar to my first proposal, with
> the difference that it applies only to elements, and not to attributes.
> However, in the current proposal, we enable the client to choose which
> language it wants to see, and then we send only this language over the wire,
> thus saving bandwidth.
 OK, forget about the xml:lang I guess if we keep the "lang" bit and
"en,de,..." codes, this is already good enough to be self documented...

> >
> >  I forgot to add the proposal of an Issuzilla list (or Bugzilla?)
> >
> 
> Yes, that would be great.
> 
> > > I think about MRML<->SOAP translation for sometime. It should not be hard
> > > because both of them are based on MRML. If we can make MRML<->SOAP
> > > gateway or proxy, it will be very easy for
> >
> >            ^---- (you mean XML :-)
> >
> > > developers to develop front-ends using Java or .NET .
> 
> Yes, that would be cool. Same applies for the backend. It might be cool to
> have a soap client as a plugin for the GIFT. Then, for some people the
> overhead of writing things usable for the gift would still be reduced. Which
> makes me re-think of CORBA...
> 
> >  I suppose we should at least work inb the sense of having MRML included
> > as an XML-protocol here:
> > http://www.w3.org/2000/03/29-XML-protocol-matrix
> >  The proposal of having a number of consistencies with the W3C's other
> > specs go towards that aims (use of a namespace - mrml: -, extension
> > protocol, ...)
> 
> Yes, this would be cool (as discussed before).
 Again, the above "abstraction" would lead to the definition of MRML as
a true XML-protocol and let envisage it relation (and integration) with
other known ones (XML-RPC (XRPC?), SOAP, ...)
Cheers,
  Steph
-- 
Stephane Marchand-Maillet, PhD
Computer Vision and Multimedia Laboratory, University of Geneva
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/