[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] recordPacking: No Schema Change Required
>> 2. There will be some cannonical mapping of application/xml+sru to other >> formats -- json, ATOM and so the 'unpack' directive says that a >> particular >> variation (i.e. unpacked) of that mapping should be used? > > Not so sure about this. It may be that this falls more into 'best pactice' > rather than 'canonical'. I could imagine an informative annex (or annexes) > say (or possibly a companion doc) which would show how SRU responses could > be carried over some well-known formats, e.g. ATOM, RSS, JSON. Ok that's good enough for now, assume that there will be guidance on how an ATOM, RSS, or JSON file (possibly others) will look as an SRU response. What form that guidance takes we can figure out later, perhaps a non-normative annex or perhaps a separate document, or binding. Then, if we add additional enumerated values to the recordPacking parameter ("unpacked" for example), the binding would provide additional guidance as to how the record is to be formulated. "unpacked" would mean construct the record in the manner that you have described earlier in this discussion. The binding (or guidance document) describing how the format is rendered would describe also how it is to be constructed if "unpacked" is specified. And I imagine we would want to generalize this so that other values could be used, and those would also be addressed by the binding. So for example, recordPacking=looselyPacked&httpAccept=application/xyz Then the document which describes how application/xyz should be constructed for an SRU response would specifically address what to do if "looselyPacked" is specified. Does this make sense so far? I'm not opposed to adding this functionality. I just think that it stretches the semantics of the recordPacking parameter too far. How about if we introduce another parameter, call it 'recordFormatting'. > Are you going to perscribe for every mime type out there? E.g. a very > reasonable request (and one that we might have added but didn't - yet) > would > be 'application/rdf+xml'. I can't imagine that we would develop a binding (or guidance) for every mime type, but I do think it should be done for any mime type for which someone will implement the SRU response. That doesn't mean that WE have to do it. --Ray
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]