Compiling ideas for version 1.1
Ross Singer
I realize this might be a bit premature since there aren't really any
1.0 implementations out there not written by me, but I wanted to start
thinking about ideas on what changes needed to be in the next version
of Jangle.
Things I would like to see are:
1) Jangle Cores send their Jangle version to Connectors for connectors
to determine the functionality they want to implement based on the
feature set of the Core (this becomes more clear in a later point)
2) Associations explicitly defined in 'relationship' feeds
3) Ability for Connector to force Core to use https for specific
tasks/collections/identifiers. While obviously it can issue 30x
headers to the Core to redirect to a secure port on the connector, it
has no capability of ensuring that the Core won't retransmit this data
via http to the client. Going back to #1, this way a connector can
see that a Core doesn't support this functionality and choose not to
make Actors available, for example.
4) Send what profile(s) this connector conforms to in the Service
response -- basically if the Entities correspond to an OPAC service,
let the client know that so it has a better understanding of what the
data and relationships mean
5) Move the Jangle vocabulary to a service like http://metadataregistry.org/
Things to contemplate:
1) Using offsets are the easiest way to implement paging, however if
resources are deleted while a feed is being harvested, there are no
guarantees that this won't leave resources in the 'margins'. An
alternative would be to also allow an argument like "startIndex", but
this makes calculating page URIs much more complicated
2) We probably should create a formal definition of a "common"
profile, such as OPAC.
3) There really aren't any good CQL context sets for searching Actors
or Items (at least in an OPAC profile) -- the closest would be NorZIG,
probably: http://www.norzig.no/cql/norzig/1.0/ but it's not perfect.
A vCard context-set would be ideal for Actors (I think), but some
common elements would be useful for Items (like barcode or location,
for example)
Feel free to add any ideas you have. Should I create a page on
Jangle.org for this?
-Ross.
Ross Singer
Another useful addition to a 1.1 would be a means to specify the
default resources per feed page. Since this would probably be static,
my recommendation is that it would be defined in the connector
services response.
Without this, the Jangle core has no way to know for certain what the
"previous" page offset should be from the last page.
Anyway, pile on any and all ideas you might have for v. 1.1.
Thanks!
-Ross.
sieh...@googlemail.com
I have not tried to implement Jangle, so it can only give limited
input. One thing I disliked from the beginning is the lax formal style
of the specification - it should better look like an RFC or a W3C
recommendation at one page instead distributed at several wiki pages
(by the way there seem to be multiple jangle wikis: an open wiki at
http://code.google.com/p/jangle/w/list and a closed wiki at
jangle.org). It is still not clear to me, which parts are part of the
Jangle specification 1.0, which are part of revision 1 and which are
informal only. For instance what about the Jangle vocabulary? Is it an
defined ontology or just a random list that anyone could compile?
In particular you wrote:
> Another useful addition to a 1.1 would be a means to specify the
> default resources per feed page. Since this would probably be static,
> my recommendation is that it would be defined in the connector
> services response.
>
> Without this, the Jangle core has no way to know for certain what the
> "previous" page offset should be from the last page.
In summary the most important thing I would like to see in Jangle 1.1
is just a cleanup of Jangle 1.0 specification before making it more
complicated than it already is. I recommend to have a look at how
standards are created at W3C or IANA:
http://www.w3.org/2005/07/pubrules
http://www.rfc-editor.org/formatting.html
Greetings,
Jakob
Ross Singer
Comments inline -
On Tue, Apr 28, 2009 at 6:35 PM, jakob...@gbv.de
<sieh...@googlemail.com> wrote:
>
> Hi Ross,
>
> I have not tried to implement Jangle, so it can only give limited
> input. One thing I disliked from the beginning is the lax formal style
> of the specification - it should better look like an RFC or a W3C
> recommendation at one page instead distributed at several wiki pages
I have no problem with this in theory. Of course, when the draft was
open for public comment this issue didn't come up, so it wasn't
addressed.
That's not to say it couldn't be, but some help making it fit for
presentation would be greatly appreciated. It's a lot of work
compiling all the concepts and terms coherently and, subsequently,
some stylistic details might suffer.
Myself, I would prefer both formats (single page/broken up by
section), since I personally despise the RFC format.
> (by the way there seem to be multiple jangle wikis: an open wiki at
> http://code.google.com/p/jangle/w/list and a closed wiki at
> jangle.org).
Yes, well, this is a historical delineation. Originally, the entirety
of the project was documented into the Google Code site. This was
somewhat limiting and became a little confusing since there needed to
be some delineation between the "spec" and the "code".
This needs to be cleaned up. I'd, again, appreciate pointers or more hands.
BTW, the Jangle.org site is not "closed". It just requires
registration. If you've registered recently, I might just need to
enable your account -- there's some bug in the Drupal email feature on
our shared host.
I just approved your comments.
>It is still not clear to me, which parts are part of the
> Jangle specification 1.0, which are part of revision 1 and which are
> informal only. For instance what about the Jangle vocabulary? Is it an
> defined ontology or just a random list that anyone could compile?
Hrm, well... The idea here is a community editable registry of
resource formats that could be used for any spec (so, for example,
UnAPI). It does not need to be hosted on jangle.org (in fact, I would
prefer it wasn't) - but nobody offered any alternatives and it had to
go somewhere.
If anybody's interested in working with me on this, I will be happy to
move this vocabulary to metadataregistry.org or open.vocab.org.
Drupal was not a good medium for this.
The Entities are controlled, so I'll turn that into something more formal.
The 'terms' are merely intended to be a shared vocabulary to provide
URIs for particular concepts inherent to libraries: holds, recalls,
copies, holdings, etc. This way we can just defer to Atom categories
to further refine resources, but not have ambiguity about what the
categories actually mean (especially since different libraries use the
same term for different meanings).
>
> In particular you wrote:
>
>> Another useful addition to a 1.1 would be a means to specify the
>> default resources per feed page. Since this would probably be static,
>> my recommendation is that it would be defined in the connector
>> services response.
>>
>> Without this, the Jangle core has no way to know for certain what the
>> "previous" page offset should be from the last page.
>
> Doesn't RFC 5005 fullfill the needs of paging?
Yes, for the Atom feed. The problem is that the Jangle core doesn't
know how many resources per page the connector is sending. So, the
last page of a particular feed:
http://connector.jangle.org/resources/?offset=6000
There are 77 'resources' in that page. The Jangle core (since it's
connector agnostic) has no idea how many the "default" should be for
the link rel='previous' tag. It can only assume it's 77 and make the
previous page offset:
http://connector.jangle.org/resources/?offset=5923
which is, to say the least, clunky.
So, the problem is *before* RFC 5005 enters the picture.
If the connector services response included a 'itemsPerPage' parameter
for each entity, the Jangle Core could know precisely how to page the
results when it first registers the connector.
>
> In summary the most important thing I would like to see in Jangle 1.1
> is just a cleanup of Jangle 1.0 specification before making it more
> complicated than it already is. I recommend to have a look at how
> standards are created at W3C or IANA:
>
> http://www.w3.org/2005/07/pubrules
> http://www.rfc-editor.org/formatting.html
Duly noted. The best way this will happen is to provide commentary
when the spec revision is open for feedback (or, even better, be
involved in the draft process).
-Ross.
Ross Singer
In version 1.0, the stylesheet attribute of a resource in a connector
feed response is a string, but for the stylesheet attribute at the
root level it's an array - the idea being that you should be able to
layer XSLTs.
I propose that we turn the element level stylesheet field into an
array as well, since everything you can do at the feed level you
should be able to do at the item level (since feeds may be
heterogeneous).
-Ross.