Explicitly defining Jangle relationships
Ross Singer
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
different ways to do this (mostly out of experimentation than
prescription).
The original design incorporated Jangle-specific link relationships.
RFC 4287 allows for the extension of Atom with other vocabularies by
using URIs in the rel attribute in link tags
(http://atomenabled.org/developers/syndication/#extensibility), so,
for every internal Jangle relationship, the feeds had two link tags
for alternate record formats:
<link rel="alternate"
type="application/atom+xml;format=application/marc"
href="http://jangle.example.org/foo_service/resources/1234?format=application/marc"
/>
<link rel="http://jangle.org/rel/alternate#application/marc"
type="application/atom+xml;format=application/marc"
href="http://jangle.example.org/foo_service/resources/1234?format=application/marc"
/>
It kept the default alternate link tag to allow non-Jangle aware
clients to still navigate the relationships using, say, assumptions
and heuristics.
Although I never implemented it in the demo, the same concept could
have applied to related links:
<link rel="related" type="application/atom+xml"
href="http://jangle.example.org/foo_service/items/5678" />
<link rel="http://jangle.org/rel/related#Item"
type="application/atom+xml"
href="http://jangle.example.org/foo_service/items/5678" />
Currently 'related' just uses the heuristics method, since it should
be pretty easy to parse actors, resources, collections, and items in a
URL. This is a super-weak argument and seriously flawed design
non-decision, of course, and doesn't allow for the possibility of
either:
A) addition of Jangle core entities
B) local path names to the defined Entities (i.e. the service document
defines the path /foo/borrowers as the default path for Actors in the
foo service)
So, the upside of this is explicit definition. The downside is
duplication of data. A Jangle client would need to dedupe the link
element hrefs in many cases (since there may be legitimate alternate
and related links *outside* the Jangle relationships).
And it is here that I humbly recommend turning to an extension and
adding some namespaced attributes to the link element.
So, perhaps it could look something like:
<feed xmlns:jangle="http://jangle.org/terms">
<link rel="alternate"
jangle:rel="http://jangle.org/terms#application/marc"
type="application/atom+xml;format=application/marc"
href="http://jangle.example.org/foo_service/resources/1234?format=application/marc"
/>
<link rel="related" jangle:rel="http://jangle.org/terms#Item"
type="application/atom+xml"
href="http://jangle.example.org/foo_service/items/5678" />
...
</feed>
I'm not necessarily suggesting that the above is how it needs to look
or work, but throw it out there to give people something to provide
comments, criticism and alternatives to.
I'd like to come to some kind of rough agreement on how to implement
this by the end of the week (either by just going with the status quo
"2 elements per relationship" design or a new extension attribute).
Thanks,
-Ross.
Ross Singer
dramatically change the functionality, I'm going to table this for now
and maintain the status quo (two link elements for each relationship).
We can address it later if people want (I mean, I want -- I just
don't want to start making extensions without some community
discussion).
Of course, if the community wants to come alive in the next three
hours and weigh in with a yea or nay, that's welcome, too.
-Ross.
Mike Rylander
>
> Ok, there's been no response to this proposal. Since it doesn't
> dramatically change the functionality, I'm going to table this for now
> and maintain the status quo (two link elements for each relationship).
> We can address it later if people want (I mean, I want -- I just
> don't want to start making extensions without some community
> discussion).
>
> Of course, if the community wants to come alive in the next three
> hours and weigh in with a yea or nay, that's welcome, too.
Well, if you're going to put it /that/ way ...
I think this is a perfect example of how an extension can be created,
inserted and used without reinventing any wheels, and at the same time
gaining /tonnes/ in terms of terse-osity (usually a good thing)...
IOW, I like attribute-only additions (extensions) that do things like
remove redundant element with a simple, semanticaly useful descriptive
marker.
+1
--miker
--
Mike Rylander
| VP, Research and Design
| Equinox Software, Inc. / The Evergreen Experts
| phone: 1-877-OPEN-ILS (673-6457)
| email: mi...@esilibrary.com
| web: http://www.esilibrary.com
Ross Singer
> IOW, I like attribute-only additions (extensions) that do things like
> remove redundant element with a simple, semanticaly useful descriptive
> marker.
>
I agree. Of course the recommendation I made has approximately zero
thought put into it.
The things that would need to be decided:
- What exactly are we defining with the attribute?
By this I mean, the semantics would be dependent on the value of the
rel attribute. rel="alternate" would need to define what the
alternate payload format is. rel="related" would need to describe
what the relationship is.
While I think it's no problem to do these both via URIs, should they
be defined with different attribute names? What should it/they be
called?
- Is there anything else we'd like to define as well?
- Has anybody written a schema for this sort of thing before (Mike, I
know you dabbed in OpenSearch relevancy at one point)? Any opinions
on what the namespace should be?
-Ross.
Mike Rylander
>
> On Fri, Aug 1, 2008 at 4:06 PM, Mike Rylander <mryl...@gmail.com> wrote:
>
>> IOW, I like attribute-only additions (extensions) that do things like
>> remove redundant element with a simple, semanticaly useful descriptive
>> marker.
>>
>
> I agree. Of course the recommendation I made has approximately zero
> thought put into it.
>
> The things that would need to be decided:
>
> - What exactly are we defining with the attribute?
> By this I mean, the semantics would be dependent on the value of the
> rel attribute. rel="alternate" would need to define what the
> alternate payload format is. rel="related" would need to describe
> what the relationship is.
>
> While I think it's no problem to do these both via URIs, should they
> be defined with different attribute names? What should it/they be
> called?
>
My first instinct is to say yes, because, as you point out, the
purposes are different. Perhaps it makes sense to use @jangle:related
and @jangle:alternate, which has the benefits of being self-describing
(and may make code generation/development easier) and provides a
cross-check for Jangle correctness.
> - Is there anything else we'd like to define as well?
Not yet, says I.
>
> - Has anybody written a schema for this sort of thing before (Mike, I
> know you dabbed in OpenSearch relevancy at one point)? Any opinions
> on what the namespace should be?
>
Dabbled is right ... all of that is long forgotten now, and being the
barest of prototypes, there was no XSD.
--miker