[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]