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

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

Hi everybody,
	here you are my "vacation" thoughts/comments about the different points, just 
inline:

Martin Senger wrote:
> Hi all,
> 
> Thank you for all comments and suggestions. Here is a summary. Before
> we consider it as an RFC we still need to answer few questions.
> 
> [So this not yet a call to vote, but it is close to it, I hope. I
> would rather prefer Mark to make the call when the time is appropriate
> and the RFC clear.]
> 
> -------
> a) There is one change in the service registration (and, consequently,
> in the findService() response): A new property "allowingRefs" that
> contains a list of one or more protocols names (e.g. http or ftp). A
> service having this property non-empty is able both accepting
> references from clients and producing references in its responses.
> 
> Commentary: I would leave it to the Mark/Eddie to specify how exactly
> this new property appears in the registration and in the findService.
> 

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.

> -------
> b) A client asks for getting back references by including "acceptRefs"
> attribute in mobyData tag. The attribute lists one or more protocol
> names that the client can accept. For example: acceptRefs="http,ftp".
> A client can also send its input data by reference - but only to the
> services that has a non-empty property "allowingRefs".
> 

As all mobyData blocks are sent to the same service, I'd rather attach 
"acceptRefs" to mobyContent instead of mobyData, but it is only to avoid 
redundancy.

> -------
> c) A service can obey a request for references.
> 
> Question: A service can obey or should obey?
> 

These are some scenarios:

1)	A client cannot understand references, so the service's answers do not 
contain references.
2)	A service cannot generate references, so the service's answers do not 
contain references.
3)	A client tells what kind of references it understands, but it is not the 
same subset as the service is able to generate, so the service's answer do not 
contain references.
4)	There is a common subset of reference types understood by both the client 
and the service, so the service's answer does contain references (if it is 
needed).

Surely there are more interesting scenarios out there.

> -------
> d) The format of references: The references are expressed as an
> XInclude element, with the namespace
> http://www.w3.org/2001/XInclude. For example:
> 
>       <moby:Simple moby:articleName="sequence" xmlns:xi="
> http://www.w3.org/2001/XInclude">
>         <moby:FASTA_AA>
>           <moby:String moby:articleName="content">
>              <xi:include parse="text" href="
> http://www.uniprot.org/uniprot/Q25158.fasta"/>
>           </moby:String>
>         </moby:FASTA_AA>
>       </moby:Simple>
> 
> Notice that in this example, there is a "text" - meaning that the
> references data are non-XML, non-escaped raw data. Such as (notice the
> non-escaped "greater-than" sign):
> 
>> sp|Q25158|OPSC2_HEMSA Compound eye opsin BCRH2 OS=Hemigrapsus sanguineus
> PE=2 SV=1
> MTNATGPQMAYYGAASMDFGYPEGVSIVDFVRPEIKPYVHQHWYNYPPVNPMWHYLLGVI
> YLFLGTVSIFGNGLVIYLFNKSAALRTPANILVVNLALSDLIMLTTNVPFFTYNCFSGGV
> WMFSPQYCEIYACLGAITGVCSIWLLCMISFDRYNIICNGFNGPKLTTGKAVVFALISWV
> IAIGCALPPFFGWGNYILEGILDSCSYDYLTQDFNTFSYNIFIFVFDYFLPAAIIVFSYV
> FIVKAIFAHEAAMRAQAKKMNVSTLRSNEADAQRAEIRIAKTALVNVSLWFICWTPYALI
> SLKGVMGDTSGITPLVSTLPALLAKSCSCYNPFVYAISHPKYRLAITQHLPWFCVHETET
> KSNDDSQSNSTVAQDKA
> 
> Commentary, questions:
> 
> i) I am not sure if we should use XInclude (as
> above) or rather XLink. Their differences are blurned for me.
> 

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

> ii) If using XInclude, are we going to allow also the attribute
> "xpointer"? I hope not...
> 

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. Perhaps Saxon in Java side, but I don't know...

> -------
> e) Location of references: The references may be placed inside any XML
> tag within a BioMoby message.
> 
> Commentary: God bless those who are going to implement it...
> 

It would be very easy using "xpointer" feature from XInclude, and in that case 
the sentence would be again right: "God bless those who are going to implement 
it..."

> -------
> f) Protocol and format of the referenced data: The protocol how to get
> data is specified in the "href" attribute of the "xi:include" tag.
> 
> The format of referenced data depends where the "xi:include" tag is
> used:
> 
> If it is used on any other tag than the primitive type, it has
> to be an XML complying with the BioMoby message specification, and the
> "xi:include" tag should have the parse="xml" attribute (or none at
> all). The same for primitive types when parse="xml" is used.
> 
> For primitive types with parse="text", the referenced data may be
> encoded differently as they would in a regular BioMoby message. The
> new encoding can be specified in the "encoding" attribute of the
> "xi:include" tag, or - if the HTTP protocol is used - in the HTTP
> header "Content-type".
> 
> Cheers,
> Martin
> 

	Nice holidays,
		José María

-- 
"There is no reason why anybody would want a computer in their home" -
	Ken Olson, founder of DEC 1977
"640K ought to be enough for anybody" - Bill Gates, 1981
"Nobody will ever outgrow a 20Mb hard drive." - ???

"Premature optimization is the root of all evil." - Donald Knuth

José María Fernández González
Tlfn: (+34) 91 732 80 00 / 91 224 69 00 (ext 3061)
e-mail: jmfernandez at cnio.es		Fax: (+34) 91 224 69 76
Unidad del Instituto Nacional de Bioinformática
Biología Estructural y Biocomputación	Structural Biology and Biocomputing
Centro Nacional de Investigaciones Oncológicas
C.P.: 28029				Zip Code: 28029
C/. Melchor Fernández Almagro, 3	Madrid (Spain)


**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en su caso los ficheros adjuntos, pueden contener información protegida para el uso exclusivo de su destinatario. Se prohíbe la distribución, reproducción o cualquier otro tipo de transmisión por parte de otra persona que no sea el destinatario. Si usted recibe por error este correo, se ruega comunicarlo al remitente y borrar el mensaje recibido.
**CONFIDENTIALITY NOTICE** This email communication and any attachments may contain confidential and privileged information for the sole use of the designated recipient named above. Distribution, reproduction or any other use of this transmission by any party other than the intended recipient is prohibited. If you are not the intended recipient please contact the sender and delete all copies.