OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

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


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]