Re: [help-GIFT] Looking for an MRML DTD

[Wolfgang Müller]

Hi Phil,

> Hope you are well.  

Same to you.

> In answer to your questions: 

> DTD / MRML:
> In light of the below, I have decided I am going to create my own
> DTD as close to 100% compliant with the v2 MRML specification as
> possible and obviously distribute it to anyone who wants it.
> Mainly because as you point out, the one supplied with GIFT does
> not actually comply with the current v2 MRML spec (at:
> http://www.mrml.net/specification/v2_0/index.html) in a number of
> areas.

As that is MRML 1, and the basis for what Steph made MRML 2, this is not so 
suprising that there are changes.

> By the way, your examples below of the "get-configuration"
> and "get-server-properties" tags not being implemented by GIFT
> made me notice that these two tags are NOT in fact explicitly
> mentioned in the MRML v2 spec either.

I guess it turned out that there was not so much need for them so far.

> The necessity of a "get-server-properties" is intimated in
> the "Defining an MRML connection" section of the spec but the
> actual tag is not explicitly defined.  It is in v1 of the spec
> though.  I think it should be explicitly mentioned as the tag to
> use for this purpose in v2; what do you think?
> I am certainly putting it in my DTD and implementing it in my
> server/client code.

Nice.

> Furthermore "get-configuration" is not mentioned in v1 or v2 MRML
> specs.  Do you mean this to be a tag for achieving the
> functionality relating to server administration as defined in
> the "Managing the server" section of the v2 spec?

> Because it is not needed in the connection process as the client
> sends a get-server-properties message which is replied too by the
> server with a list of algorithms and collections plus basic server
> details all inside a "server" tag, at which point the client sends
> a get-session message and so on...
> When would "get-configuration" be used?
> If it is, I think it should be in the v2 spec.

As I did not write MRML v2, I think these are questions to ask Stephane 
Marchand-Maillet. I will CC him, to make this stick out from the other 
help-gift messages he gets.

> FOCUS OF MY PROJECT:
> The focus of my project is to produce an MRML client server pair
> that is easy for anyone to add their own feature extraction
> algorithms too and their own search algorithms too.  i.e. a main
> goal is to keep it modular whereby the core MRML functionality is
> easily decoupled from not only the two aforementioned algorithm
> types but even the GUI's.  

I thought the server was well separated from the client.

> This is so anyone can take my work 
> and 'bolt-on' there own algorithms and even a more complex GUI
> (mine will be very simple) without having to mess around with the
> actual client server part.  

For bolting in your own algorithms and accessors you don't have to mess with 
sockets within GIFT, I assure you. You get XML as input, you give XML as 
output.

> They should be able to simply reply on 
> it doing the MRML protocol stuff.  I am hoping to provide
> installation, user and development manuals to go with it.

Yes, that'd be cool.

> Another goal is that it has few if any dependences.  Unlike GIFT
> where apparently it is necessary (I haven't actually tried to
> install GIFT myself) to install emulators, supporting languages
> etc.  

Josh's problem with GIFT was, that he did not want to install GNU/Linux to 
make the GIFT run. If you try to run GIFT using Cygwin there are some 
problems due to dynamic linking.

How bad problems are concerning the perl prerequisites, depends very much on 
the GNU/Linux distro you're using. If you're using Debian GNU/Linux for 
example, then GIFT is a one-click install (at least it was last time I 
tried).

> Hopefully mine will install (client, server or both) with 
> the clink of a button.
> Another objective is to remove the requirement to have a third
> party web server on the machine on which the server is installed.

...this is again a windows thing. I know few GNU/Linux machines that are not 
running a web server.

> i.e. my server will be self-contained; by definition a true server
> in itself.

Thou shalt not run other servers but myself? :-D

> SOAP / RPC:
> I am definitely using SOAP.  

It's good to see that a suggestion I gave is taken seriously.

> SOAP in my opinion is tailor made for 
> our (MRML 'peoples') purposes.  

I agree with that.

> It provides us the ability to send 
> XML (and therefore MRML) messages between programs over the
> internet; which is exactly what we need; it has no problems with
> firewalls and proxy servers; its platform independent and easily
> wrapped by HTTP using readily available libraries in Java and .NET.

Which was surely not the case when MRML v1 was written which is the reason why 
it uses the subset of XML it uses.

> But I think the most compelling reason to use SOAP for an MRML
> implementation is that you can send binary attachments along with
> the SOAP message using SOAP With Attachments.  Which is perfectly
> tailored to the QBE paradigm.
>
> My client will send the actual multimedia query file to the server
> as a SOAP attachment.  This way the server can extract the
> features and search the selected collection for matching features
> that were extracted with the same extraction algorithm. What are
> you thoughts?

As only possibility, I don't think it's a good idea. Sending the URL makes the 
server decide if it knows the media item or if it does not know the media 
item. If it does not know the media item, it will download it. Same for 
client-side caching of media items. As add-on it might make easier to post 
images that are not on the web.

> INCLUDING PROPERTY SHEETS:
> Property sheets have been 'dropped' in the v2 spec to be replaced
> by XForms haven't they?
> Do you mean XForms?

Yes. I think parts of my problems with your mail was that I did not know which 
version of MRML you meant and which you meant to implement. Do you know of an 
MRML client actually using MRMLv2 property sheets based on XForms?

Cheers,
Wolfgang