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

[José María Fernández González]

Hi everybody,
	there is a fourth option, where it is not mandatory to have an article 
name for primary inputs: primary inputs must be submitted in the same 
order as they were declared at service registration, and they are 
expected to arrive so to the service. Even it could happen that no 
primary input had an article name!

	But there is a drawback: service coding should be more coupled to 
service declaration in order to take into account the input parameters 
order, so this option is more error-prone.

	Best Regards,
		José María

Martin Senger wrote:
>>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
> 

-- 
José María Fernández González		e-mail: jmfernandez at cnb.uam.es
Tlfn:	(+34) 91 585 54 50		Fax:	(+34) 91 585 45 06
Grupo de Diseño de Proteinas		Protein Design Group
Centro Nacional de Biotecnología	National Center of Biotechnology
C.P.: 28049				Zip Code: 28049
C/. Darwin nº 3 (Campus Cantoblanco, U. Autónoma), Madrid (Spain)