[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft of "Annex D - Extensions for Alternative Response Formats"for Review
Hi All:
Attached is a draft "Annex D - Extensions for Alternative Response Formats"
for review.
Before going further there are some questions that should be raised. If I
could get a sense of this group's thoughts on these questions that would be
very helpful. (Sorry - mail is long.)
1. I've gone along with the notion of a 'responseType' parameter to
select the particular format within a content-type. However, I've introduced
the notion of default formats (being those shown here) which could obviate
the need for having to use this parameter if the standard response types are
used.
- Is that reasonable? (That there can be a default format for a content
type?)
- Also at some point one does wonder how useful this parameter really
is. See later for deliberations on whether the srtuctures really change that
much. Or whether they are even that well specified in the first place.
2. There's a wrinkle with RSS. In theory RSS 2.0 is usually specified
with mime type 'application/rss+xml' and RSS 1.0 with 'application/rdf+xml'.
In practice, client software generally expects '.../rss+xml' for either
flavour. We recognized this dilemma in the CrossRef recommendations for RSS
[1] (and see especially [2]) which ends up recommending 'application/xml'.
- I have added both RSS flavours under mime type '.../rss+xml' making
RSS 1.0 the default. Some may prefer to make RSS 2.0 the default. (Note that
CrossRef especially recommends RSS 1.0 for interop reasons - data model,
etc.)
- One way out of this impasse would be to use '.../rss+xml' for RSS 2.0
and '.../rdf+xml' for RSS 1.0 (although that might usurp any other RDF/XML
serialization). But then we run foul again of client software expectations.
I guess I'm in favour here of keeping '.../rss+xml' as single mime tyep for
RSS.
- (Of course, problem goes away if RSS 2.0 goes away. Could you live
with that, Ralph? OK just joking. ;)
- Thoughts?
3. The examples only really show the record data handling plus one
toplevel element: numberOfRecords. They don't show other toplevel elements
(e.g. extraReponseData) which raises questions about their ordering
(unimportant), naming (what is allowed), and also their substructures.
- I don't know how to handle this last (especially) without turning the
annex into a handbook. Are the response types indicative or prescriptive?
4. There are two levels of organization: the main structure and the
record data substructure. I don't believe there needs to be much variance in
the main structures (although RSS maybe belies that - depending on whether
these are viewed as siblings mimetypes or different). What does vary (and
will from producer to producer) is the record data payload. I guess we
should allow latitude in that and only use response type to denote a major
variance in the main structures. Is that reasonable?
- Record data structure is where my 'unpacked' notion came in. Is it
flat or structured as per the original XSD? Does responseType apply to the
record data organization? Should there be one or more possibilities to
arrange the record data elements?
5. Namespaces (especially in JSON). I don't know know what we should
recommend. RSS 1.0 (as RDF/XML) requires all elements (but RSS) - and
attributes - to be namespaced. Good practice would indicate that that is a
sensible policy. However with JSON there is a problem. With NPG's JSON we
have namespaced as 'dc:term' and 'prims:term' and then also included a
namespace table within the feed. Where the OpenSEarch folks are going is
hard to say. They probably want to drop namespaces altogther. But that
doesn't help with metadata. One possibility is to use objects for namespaces
(which is proper JSON way of compartmentalizing), e,g,
a) namespace objects
'dc': {
'title': 'string',
'creator': [ 'string', 'string' ....],
...
}
b) flat namespace
'dc:title': 'string',
'dc:creator': [ 'string', 'string' ....],
...
c) no namespace
'title': 'string',
'creator': [ 'string', 'string' ....],
...
- I guess I don't favour c) because of collisions. What we did in NPG
service is b) although in two forms (one for packed and one for unpacked -
but actual elements were all namespaced). Although note in NPG both forms
have same structure (or response type) - it's just the data properties that
wander.
- One optimized JSON rendering would be to use the model a). (Note that
this is orthogonal to the question of whether to keep the properties at the
schema level (packed) or at the item level (unpacked). To show that once
again for LOC data see at end of this mail for some possibilities (the first
two SRU oriented, the second two OpenSearch oriented).
6. Note that JSONP needs to be elevated to a toplevel response type as
the mime type is changed. (And JSONP is arguable more useful than JSON -
although both should be supported.)
There were some smaller points but I guess those can wait for now.
Cheers,
Tony
[1] http://oxford.crossref.org/best_practice/rss/
[2]
http://oxford.crossref.org/best_practice/rss/#9_Notes_on_Media_Types_9035408
070876731
==
A.
{
"id": "urn:isbn:1868720721",
"title": "The hitchiker's guide ...",
"link": "http://www.example.com/abc";,
"updated": "2009-12-12T12:00:00Z",
"sru:recordSchema": "info:srw/schema/1/dc-v1.1",
"sru:recordPacking": "xml",
"sru:recordData": {
"srw_dc:dc": {
"dc:title": "The hitchiker's guide ...",
"dc:creator": [
"Goldstuck, A."
],
"dc:type": "text",
"dc:publisher": "Johannesburg : [S.N.]",
"dc:date": "1998",
"dc:language": "eng",
"dc:identifier": "urn:isbn:1868720721"
}
},
B.
{
"id": "urn:isbn:1868720721",
"title": "The hitchiker's guide ...",
"link": "http://www.example.com/abc";,
"updated": "2009-12-12T12:00:00Z",
"sru:recordSchema": "info:srw/schema/1/dc-v1.1",
"sru:recordPacking": "xml",
"sru:recordData": {
"dc": {
"title": "The hitchiker's guide ...",
"creator": [
"Goldstuck, A."
],
"type": "text",
"publisher": "Johannesburg : [S.N.]",
"date": "1998",
"language": "eng",
"identifier": "urn:isbn:1868720721"
}
},
C.
{
"id": "urn:isbn:1868720721",
"title": "The hitchiker's guide ...",
"link": "http://www.example.com/abc";,
"updated": "2009-12-12T12:00:00Z",
"dc:title": "The hitchiker's guide ...",
"dc:creator": [
"Goldstuck, A."
],
"dc:type": "text",
"dc:publisher": "Johannesburg : [S.N.]",
"dc:date": "1998",
"dc:language": "eng",
"dc:identifier": "urn:isbn:1868720721"
},
D.
{
"id": "urn:isbn:1868720721",
"title": "The hitchiker's guide ...",
"link": "http://www.example.com/abc";,
"updated": "2009-12-12T12:00:00Z",
"dc": {
"title": "The hitchiker's guide ...",
"creator": [
"Goldstuck, A."
],
"type": "text",
"publisher": "Johannesburg : [S.N.]",
"date": "1998",
"language": "eng",
"identifier": "urn:isbn:1868720721"
}
},
==
********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is
not the original intended recipient. If you have received this e-mail in error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number 785998
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]