Draft spec reminder and a couple of revision ideas

Skip to first unread message

Ross Singer

Oct 10, 2008, 10:53:02 AM10/10/08
to jangle-...@googlegroups.com
Hi everybody,

I just wanted to remind you all that the draft spec is up and ready
for your comments at: http://jangle.org/drupal/1_0rev1spec

Again, I really would like to see this spec do a formal release at the
end of the month, so anything you want changed, clarified, added or
removed, get them in soon.

Which brings me two possible changes:

Sam Tunnicliffe noted that for the HTTP header sent from the Jangle
core to the connector to let it know its base URI should really be
changed from Connector-Base to X-Connector-Base, since it's not a
standard header.

Any objections? Comments?

I had a realization this morning that there's not really a way to
determine (simply) what the data format for a given feed... What I
mean is, we state the data format of alternate feeds explicitly, but
there's no indication of a Jangle format URI in the feed you're
actually looking at, so how would you know, for example, that you're
looking at a feed containing RDF/DC content elements?

I have three possible proposals for this for you all to vote up or down on:

If the feed is homogeneous with regard to its data types, include a
jangle extension attribute:
<link rel="self"
href=".." />

However, the expectation that all feeds will be homogeneous like this
is, in my mind, unrealistic.

So the next possibility would be to take the same syntax and apply it
to the atom:feed/atom:entry level:

<link rel="self"
href=".." />

This helps alleviate the problem with heterogeneous collection of data
formats. However, I'm not totally sure this is the right place for
this, although I'm not opposed to it (and I do really like the
consistency of syntax that could be used for homogeneous or
heterogeneous feeds at the feed or entry level).

The last option would be to add the jangle extension attribute to the
atom:entry/atom:content element:
<content type="application/rdf+xml"

This has the advantages of explicitly being tied to where the data
format actually resides (so if, in the future, we decided to make a
further jangle extension to include all metadata formats, for example,
it wouldn't be affected by that). However, there's no consistent
analog to use at the feed level.

So, I'd like to see some +1s or -1s regarding this by next Friday
(10/17), or I'll just add the first and second options (link

Alternatives also welcome.



Oct 13, 2008, 10:16:08 AM10/13/08
to jangle-discuss
Addendum to this:

In order to make this work, it needs to be added to the connector JSON
as well.

So, I'm proposing adding:

an array "formats" to the base level of the JSON object which contains
all of the format URIs contained in the feed.

"format", a string, in the resource object which contains the format
URI of the resource itself.

I've added these to JangleR and if there's no objections, I'll add
them to the spec revision for Friday.

Reply all
Reply to author
0 new messages