You cannot post messages because only members can post, and you are not currently a member.
|
Search Query Syntax
|
| |
It would be helpful, in my mind, if Jangle implementations had a common search syntax. What I mean here is beyond the OpenSearch description document, but actually identifying how to construct specific searches within a given resource (such as a date span or some such). My initial impression is that OpenSearch's parameterized query syntax is too limiting and not... more »
|
|
|
Straw Proposal for Jangle Connector JSON refactor
|
| |
Ok, after some consideration, here is a proposal for (in my mind) improved JSON response for a 'feed' request (i.e., your normal connector response). It's quite different from the current response. In the "root" of the response, there are some new elements ("type", "formats", "alternate_formats", "stylesheets" and "availableResults").... more »
|
|
|
Jangle feeds and deleted records
|
| |
Hi everybody. Currently Jangle has no capacity to deal with resources removed or deleted from a particular entity (Actors, Resources, Collections, Items), because that's not explicitly baked into generic Atom. At the DLF ILS-DI BDI (#code4lib's @ana command returns "Fill did bid" for that), the requirement was laid out that to fully comply with the... more »
|
|
|
TalisLMS Connector for Jangle
|
| |
Hi everybody. I realize it has been a while since I wrote to the group as a whole. Jim Farrugia and I have been putting the final touches on the Jangle article for the Code4lib journal and I have been working on a connector for TalisLMS. The latter is coming along well, you can see some examples here:... more »
|
|
|
Explicitly defining Jangle relationships
|
| |
Hi everybody. Elliot and I recently had a conversation off-list regarding how to identify the relationships between resources exposed by Jangle. Jangle has been doing this via link elements (alternate for transporting different metadata formats and related for establishing the relationships between entities) but has employed a couple of... more »
|
|
|
One more API response proposal
|
| |
Not sure I'm waiting until _after_ the first draft of the article is in for all these ideas, but, here goes. This one may appeal to Richard, et. al. I think it would be a good idea to also have an optional 'stylesheet' field - a URI to an xsl file, for example, to allow the Jangle core to turn, say, MARCXML into DC. This would have to be at the 'data' or... more »
|
|
|
Proposal for change to JSON responses
|
| |
One thing that writing the Jangle article has done has made me realize that I don't like some of the decisions I've made up until now :) One of the things Elliot made a good point about last week was that connector developers shouldn't need to know how their data is going to be serialized (i.e. they shouldn't need to know whether something will... more »
|
|
|
Connector URIs
|
| |
Until now, I had been operating under the assumption that connectors should only need to send relative URIs to refer to their paths/ids. [1] This assumption breaks down, however, if the URI needs to be included in the actual atom entry payload, however. There's no way for the Jangle core to know when it's appropriate to make a relative... more »
|
|
|
ILS-DI item and holding information
|
| |
Hi all, As I mentioned on code4lib, I'm converting a PHP class I wrote that screen-scrapes Innovative catalogs to match the DLF ILS-DI tech recommendations. My first question (kinda long, sorry) has to do with the apparent difference between how 'GetAvailability' and 'GetRecords' treat item and holding information.... more »
|
|
|
New topic: Should Jangle connectors use Badgerfish or other conventions?
|
| |
One of the things I just ran into while writing the article is that the Jangle connectors don't have a very robust system for dealing with Atom extensions. They get by with OpenSearch, but that's only because OpenSearch elements don't use attributes (or, in the case of the description document, it's known what those attributes would be).... more »
|
|
|
Discussion group for Project Jangle - Just another generic library environment