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

[Martin Senger]

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

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.


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

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

-- 
Martin Senger
email: martin.senger at gmail.com,m.senger at cgiar.org
skype: martinsenger