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

[Phil McConchie]

Hi Wolfgang,
Hope you are well.  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.

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.
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.

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.

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.  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.  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.

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.  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.
i.e. my server will be self-contained; by definition a true server
in itself.

SOAP / RPC:
I am definitely using SOAP.  SOAP in my opinion is tailor made for
our (MRML 'peoples') purposes.  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.
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?

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

Regards, Phil.




-----Original Message-----
From: Wolfgang Müller [mailto:address@hidden
Sent: 10 August 2004 09:38
To: address@hidden
Cc: address@hidden
Subject: Re: [help-GIFT] Looking for an MRML DTD

On Thursday 05 August 2004 17:50, Phil McConchie wrote:
> Hi,
Hi,

Bayreuth had lots of problems with their mail server, so your
reply has not
arrived here, yet, so I do some cut and paste and answer that.

> Wolfgang,
> Re DTD:
> Oh OK, I have read in the specs about one of the primary
objectives being
> extensibility but thought that there might be an XML DTD
floating about that
> nailed down the exact element and attribute names for those
parts of MRML
> that appear from the specs to be concrete.

I think the most concrete DTD in use is that within the GIFT
distro. However,
it blithely ignores things like get-configuration and get-server-
properties,
as they are "stubs" added to the DTD for the case where someone
wants to do
something more complicated.

> Such as tags for "get-configuration", "get-server-properties"
etc.

> Perhaps the chap you mention who has been investigating the
practicalities
> of MRML implementations would indeed be someone to start with.
Is he on
> this list?

Even better, still, he is on the list, and he is easily reachable,
as he is
head of the Viper group in Geneva.

http://vision.unige.ch/members/Stephane_Marchand-Maillet.html

> I figure that anyone who has done an MRML implementation must
have a MRML
> DTD and we might as well move towards some kind of
standardisation for at
> least the tags that will be definitely included in any final
version.

./dtd/mrml.dtd within the GIFT package.

> I would be very interested in seeing your students' error list.
If you
> could forward my address as you suggest it would be much
appreciated.

I will do so.

> Yes, Josh is my project supervisor.  It's not problem asking
project related
> questions on this list.

There is a long version to this question, the short one is:
1. what's the focus of your project?
2. Will you look into XML-RPC and SOAP as possible containers of
MRML(-like)
messages?

> Incidentally, how many subscribers to this list are
> there?

I dunno. 60-odd.

> I am working on this project fulltime at the moment and hope to
have the
> coding more or less finished in 2 weeks.

Oh, this would be fast. Including property sheets?

Cheers,
Wolfgang


--
Dr. Wolfgang Müller
LS AI 1
Universität Bayreuth


________________________________________________________________
Sent via the EV1 webmail system at mail.ev1.net