Hi Christian,
> the RESTXQ spec. or/and our implementation may need to be extended to
> support subtypes. Reg. your use case.. Do you depend on the support of
> subtypes, or would it "just" make life easier?
Aren't subtypes already supported by RESTXQ? I was talking about the
parameters of a media type which is the "type=entry" part in the
following media type:
application/atom+xml;type=entry
I've used such parameters in "produces" as in
%rest:produces("application/atom+xml;type=entry")
I could omit this annotation but what I like in specifying this
annotations is that it will not map to media types that would not be
understood such as "application/foo" for that URI. I would like to
find a generic way of returning a 406 (not acceptable) eventually.
That is what rfc2616 suggest:
If an Accept header field is present, and if the server cannot
send a response
which is acceptable according to the combined Accept field value,
then the server SHOULD
send a 406 (not acceptable) response.
But what I understand from rfc2046 is that the server should map
according to media type and subtype and not from parameters:
MIME implementations must also ignore any parameters whose names
they do not recognize.
So I guess we could still use the full media type string along with
the parameters but that they (the parameters) are ignored by RESTXQ
for the mapping of the request to a function. Then in the response
function we could access the parameters array to figure out the
additional constraints applicable by the presence or not of some
parameters.
-- Philippe
_______________________________________________
BaseX-Talk mailing list
[email protected]
https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
