[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Service Media Type Matching
To close on this thread, the following was
recorded in the minutes of the 2006/05/25 TC telecon: * We discussed Wil's
proposal in http://lists.oasis-open.org/archives/xri/200605/msg00033.html
to add support for wildcard matching. The conclusion was that we will emulate
HTTP Accept headers and add * wildcard parameter support in the QXRI input
parameter. However we will not support publishing wildcards in
the value of a MediaType element in an XRD because the server needs to be more
explicit about what it supports. =Drummond From: Tan, William
[mailto:William.Tan@neustar.biz] Hi folks, As it is currently defined in XRI-resolution-v2.0-wd10, the
service media type in an XRD is an opaque value. This means that if the XRD
publisher wishes to express that the service offer multiple related media
types, such as image/png and image/jpg, it needs to have them individually
listed as <MediaType> elements. That is fine, but there is currently no
way for a user agent to specify more than a single service media type value for
service selection. It would be nice if we could define a more intelligent path
matching mechanism, to allow wildcards just like with regular MIME type
handling. So, Input SRVMTYPE = image/* XRD MediaType = image/jpg Result = match Input SRVMTYPE = text/html XRD MediaType = text/* Result = match Input SRVMTYPE = application/pdf XRD MediaType = application/ms-word Result = no match When a wildcard is present in the input service media type,
it means substitute anything here. When a wildcard is present in the XRD MediaType, it means
“I offer all types”. This could also be extended to */* which should still work. What do folks think? =wil (http://xri.net/=wil) |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]