[jira] [Updated] (UIMA-72) XMI-based Transport Implementation

["Richard Eckart de Castilho (JIRA)" <de...@uima.apache.org>]

     [ https://issues.apache.org/jira/browse/UIMA-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Eckart de Castilho updated UIMA-72:
-------------------------------------------
    Labels: Stale  (was: )

This issue is marked as "stale" due to inactivity for 5 years or longer. If no further activity is detected on this issue, it is scheduled be closed as 'unresolved' in 3 months time from now (Dec 2016).

> XMI-based Transport Implementation
> ----------------------------------
>
>                 Key: UIMA-72
>                 URL: https://issues.apache.org/jira/browse/UIMA-72
>             Project: UIMA
>          Issue Type: New Feature
>          Components: Transport Adapters - SOAP, Vinci
>            Reporter: Adam Lally
>            Priority: Minor
>              Labels: Stale
>
> Since XMI is the recommended XML CAS serialization format, we should support a remote service protocol that uses XMI to transport CASes.
> The OASIS specification will define a WSDL interface using XMI representation of CASes.  Once there's a draft spec. available we might want to consider implementing against that WSDL.
> One issue to deal with is "out of typesystem data".  With our current XCAS-based Vinci service, it is the service wrapper that's responsible for handling the situation where an incoming XCAS references a type that's not defined in the service's type system.  This is handled by "setting aside" any such objects (since they can't be represented in our CAS implementation) and then merging them back into the service's response.  It would be more efficient if this process were done on the client side rather than on the service side.  Also it would permit service adapters to be more easily written for other languages including C++.  (Convsersely it would make implementing the client-side adapters more complex, but there may be fewer of these necessary.)  So we may choose to move this logic to the client side when we do the XMI service adapter.
> Note that there is another, more flexible way that services could be implemented.  An incoming XMI CAS can provide a URI to its Ecore type system.  The service could retrieve that Ecore type system and reinit the CAS type system so that it could represent all the incoming data.  This would be useful for generic services like the XCAS Writer.  It also provides a better way to handle subtypes (for example the service might refer to a type system that defines the type Place but the client might want to sent instances of type City, where City is a subtype of Place).  This is probably too complex for the first implementation and is something to be left to the OASIS TC for now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)