[MOBY-dev] data by reference - a request for comments

[Sergio Ramirez Ramirez]

Hello all,

Just an small contribution

Martin Senger wrote:
>> I would split the proposed property in the two roles it plays: one for the
>> acceptable reference types, and one for the possibly generated reference
>> types. Many services will be able to accept reference types of http, ftp or
>> other kinds, but I think they usually are only able to generate answers with
>> fewer or different ones.
>>     
>
>
> I do not think that the situations will be drastically different for
> accepting and producing references - but I do not have any issue with it. I
> do not mind much how many new properties will be added to the central
> registry.
>
>   
Maybe it can be a protocol between the service and the client, the 
second sent the references that is able to handle and if they are agree 
use one of them for the comunication if not is always possible to return 
the results without use references.

If the client sent a reference (got from other service for example ) 
that the service can not handle it, an error or info notification can be 
returned to inform about that. In this case the client can resent the 
request without using references.

In this case I think is not needed to register the references that the 
service can handle in the central registry, but could be a good idea for 
searching compatible services with your data.

> As all mobyData blocks are sent to the same service, I'd rather attach
>   
Could be possible to use mirrors and separated  the mobydata to sent 
them to different mirror servers?
>   
>> "acceptRefs" to mobyContent instead of mobyData, but it is only to avoid
>> redundancy.
>>     
>
>
> Again, no problem with me.
>
> These are some scenarios:
>
>
> My question was: if a service claims that it can produce a reference, and a
> client asks for it, should the service always produce a reference? I think
> that my question was obsolete already in the time of asking it. I am
> withdrawing my question, assuming the obvious answer for the above is "yes,
> it should".
>   
Maybe we can use some kind of algorithm to see if is will be good to use 
references; for small data couldn't be useful.
Could also be defined for the client, specifying the max size that wants 
to receive (in total or by object)

> XLink (2001) was superseded by XInclude (second revision in 2006). Next
>   
>> links points to the relationship between XInclude and XLink
>>
>> http://www.w3.org/TR/xinclude/#rel-xlink
>>
>>     
>
> Yes, I saw and read this link - but, as often with me when I read the w3
> documents , I could not understand what is different, at all. I am glad,
> however, that XInclude is considered as a supersedor (I guess this word
> probably does not exist in Egnlish) of XLink. So we go with XInclude.
>
> I would love that feature because it would allow referencing fragments of
>   
>> any XML content. The only problem is that there is (almost) no memory
>> efficient implementation for XPath (used in "xpointer" feature) applied to
>> disk stored XML content.
>>     
>
>
> This is exactly why I suggested not to allow it. I would prefer to stick to
> my guns on this issue.
>
> Many thanks for replying from the holidays. What about the others? Can we go
> ahead?
>
> Cheers,
> Martin
>
>   

-- 
Sergio Ramírez Ramírez
Instituto Nacional de Bioinformática (INB)
Integrated Bioinformatics Node (GNV-5)
Dpto. de Arquitectura de Computadores
Campus Universitario de Teatinos, despacho 2.3.9a
29071 Málaga (Spain) +34 95 213 3387


"Short-term decisions tend to fail in the long-term."
            Frank Herbert, God Emperor of Dune