[MOBY-dev] Re: [personal] problem with article names?

[Martin Senger]

> then the problem already existed, and making them mandatory was an
> arbitrary decision taken more to keep the coders happy rather than for
> any solid architectural reason
>
   Well, if you knew that mandatory names bring this problem you could
tell us, and we could discuss it. I admit that I have not seen this before
David mentioned it this week. But this a history now, let's concentrate
rather on the solution.

> existed in MOBY for a long time - well before there was a decision to
> make them mandatory.
>
   The problem might have existed before, but it was not urgent because
service providers (mostly, if not all, I guess) did not check for the
missing name because it was not mandatory. Now, when it is mandatory, my
service may choose to rely on names and may refuse not-named or
badly-named inputs. So the milk may have been spilled long time ago but we
were not in the kitchen so we have not noticed it.
 
> I can see two options:  1)  we do not support named primary parameters
> at all, and thereby limit the types of services that can be created in
> MOBY to only those with unambiguous inputs/outputs; or 2)  we swallow
> the inconvenience and at least make it consistent that all
> inputs/outputs are named.
>
   I think that the option 2) is harder to achieve. Doable, but harder. It
means that all the "workflow engines" (Taverna, Ismail, Ahab, those for
sure) must find first what article name is expected by a service and tag
the output of one service by a proper name applicable for the next
service.
   I do not like option 1 - if I understand it correctly. Are you saying
that a service that takes two primary inputs, both of type
GenericSequence, would not be allowed because without naming these inputs
we cannot distinguis these sequences? If this is the case, I would
disagree with having option 1.

   What about an option 3?:
   * The primary inputs and outputs must be named (and the correct name
must be used when sending and providing) data when otherwise the input or
output would be ambiguous.
   * An unambiguos input can be send un-named and a service has to accept
it.
   * But service should refuse input that is named differently than the
service registered for.

   To achieve the last point still requires an effort on the "workflow
engines" software - they still need to change an output, but they need
only to clear the name, not to add the correct one. So they do not need
such information about the next service.
   You can also argue that the last bullet is not necessary at all. But
then the architecture would be a bit confusing (even though working): we
are saying (in such case) "a service registers for a name A, but will
accept any name". So why to register a name at all, in such case?

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger at gmail.com
   skype: martinsenger
consulting for:
   International Rice Research Institute
   Biometrics and Bioinformatics Unit
   DAPO BOX 7777, Metro Manila
   Philippines, phone: +63-2-580-5600 (ext.2324)