[
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)
