Per RFC, media types can have parameters. We should consider whether we want to make use of these or not.
For for the binary CAS formats, we could have a "form" parameter indicating a comma-separated list of accepted binary serialization formats. Another parameter "types" could be used to provide some well-known type system IDs. That would assume that people at some point start assigning URIs to type systems. Maybe a parameter whether delta-CAS is supported? Separate media types for XMI and XCAS seem more reasonable to me. Maybe even a separate media type for the CasMgr-based/Java-serialization-based forms? Maybe a minimum/maximum SDK version range? Cheers, -- Richard > On 22.08.2016, at 18:21, Richard Eckart de Castilho <[email protected]> wrote: > > +1. Was about to suggest the same. I actually subscribed to the respective > IANA > mailing list recently and read a bit about the procedure. > > The RFC says that vnd is reserved for commercial vendors, but I feel that the > ASF > should also be eligible to the vnd prefix despite being non-profit. > > We should also register the binary formats. > > Btw.: I've recently added a uimaFIT @annotation for mimetypes too and DKPro > Core is > also getting them too now. > > Cheers, > > -- Richard > >> On 22.08.2016, at 18:16, Marshall Schor <[email protected]> wrote: >> >> As people move toward REST architectures, one common kind of service is one >> that >> runs a UIMA pipeline on some data (perhaps text, or perhaps a CAS in some >> serialized form), and returns a result (perhaps in a variety of formats). >> >> One of the formats that might be returned is a serialized CAS. We have lots >> of >> forms for this. See the current version of SerialFormat enum. This enum >> currently doesn't include the approximate serialization called Inline, and >> doesn't include the multiple varieties possible in serializing in JSON >> format. >> >> Anyone implementing a service that returns a CAS, has to pick the kind of >> serialization format to return. The standard way to do this is to >> "negotiate" >> with the client, dynamically choosing the return format based on what the >> client >> sends as "Accept headers". See (for example) chapter 7 in the book "RESTful >> Web >> Services Cookbook. >> >> In order to permit this, we should adopt some standard media types, and >> perhaps >> register these with IANA. I'm thinking of names like: >> >> application/uima.xmi+xml application/uima.xcas+xml, application/uima+xml >> (for >> both xmi and xcas, receiver has to "sniff" the input to see which one), etc. >> >> application/vnd.apache.uima.xmi+xml or application/vnd.apache.uima+json etc >> >> A quick look shows Apache Thrift has registered: >> application/vnd.apache.thrift.binary ...compact ...json but that's the only >> vnd.apache there. >> >> What do people think? >> >> -Marshall
