You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2016/08/22 16:16:01 UTC
maybe registering a media type with IANA for uima
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
Re: maybe registering a media type with IANA for uima
Posted by Richard Eckart de Castilho <re...@apache.org>.
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 <re...@apache.org> 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 <ms...@schor.com> 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
Re: maybe registering a media type with IANA for uima
Posted by Richard Eckart de Castilho <re...@apache.org>.
+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 <ms...@schor.com> 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
>
Re: maybe registering a media type with IANA for uima
Posted by Marshall Schor <ms...@schor.com>.
I found this:
http://stackoverflow.com/questions/29121241/custom-content-type-is-registering-with-iana-mandatory
looking at the dirth of any apache registrations, I'd say that registration is
very optional...
which is of course not to say we shouldn't figure out something anyway, whether
or not it gets registered (for now).
-Marshall
On 8/22/2016 12:16 PM, Marshall Schor 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
>
>