Presence of wire wrapper for LIF data in LIF files

[reckart]

It seems as if it is not specified whether LIF files should some with a wire wrapper or not. Apparently data generated within LAPPS Galaxy comes with a wire wrapper so it can carry error messages in its payload instead of actual LIF data. But it seems that for normal usage of LIF files, wrapper should not be necessary.

Also, parsing files in such a way that they might or might not contain a wire wrapper is kind of hacky:

            Container container;
            String json = IOUtils.toString(res.getInputStream(), sourceEncoding);
            try {
                // First try parsing without the wire wrapper.
                container = Serializer.parse(json, Container.class);
            }
            catch (Exception e) {
                // If that fails, it might be because there is a wire wrapper around the actual
                // data, so let's try that.
                container = (Container) Serializer.parse(json, DataContainer.class).getPayload();
            }

It would be nice if

• there was a clear specification when a wire wrapper is supposed to be present
• the API should be able to deal with it nicely

Note that in the case above, doing a container = Serializer.parse(json, Container.class).getPayload() fails with a ClassCastException stating that the payload is a map which cannot be cast to Container.

[reckart]

Btw. shouldn't the HTTP code be sufficient to determine what kind of payload is in the JSON file? E.g. for 200 (SUCCESS) it should be a valid LIF document and say for 500 (INTERNAL SERVER ERROR) it should be a JSON structure describing the error.

[reckart]

The LIF specification doesn't mention a wire wrapper:

http://wiki.lappsgrid.org/interchange/overview.html

{
  "@context": "http://vocab.lappsgrid.org/context-1.0.0.jsonld",
  "metadata": { },
  "text": { },
  "views": [ ]
}

[marcverhagen]

Btw. shouldn't the HTTP code be sufficient to determine what kind of payload is in the JSON file? E.g. for 200 (SUCCESS) it should be a valid LIF document and say for 500 (INTERNAL SERVER ERROR) it should be a JSON structure describing the error.

Probably not. The payload can be a LIF document on success , but it can also be another format, for example the GATE format.

[marcverhagen]

The LIF specification doesn't mention a wire wrapper:

And it shouldn't because the wrapper would never be inside the LIF. Note that the LIF object also does not have access to the discriminator or the parameter list.

[ksuderman]

Btw. shouldn't the HTTP code be sufficient to determine what kind of payload is in the JSON file? E.g. for 200 (SUCCESS) it should be a valid LIF document and say for 500 (INTERNAL SERVER ERROR) it should be a JSON structure describing the error.

To add to what Marc said, an additional problem is that we are calling SOAP services through the Service Manager so we do not have an easy way to read or set the HTTP result codes.

[reckart]

Probably not. The payload can be a LIF document on success , but it can also be another format, for example the GATE format.

If it were a normal HTTP connection, then the content type header could be used to determine the format.

But SOAP indeed complicates the thing.

@ksuderman mentioned today a difference between a LAPPS document and a LIF document. I suppose a LAPPS document is what is being exchanged between the services and it includes the wire wrapper whereas a LIF document would be contained inside the LAPPS document as payload. In the same way, a GATE XML document could be included as payload in the LAPPS document. If that is the case, then maybe it would be reasonable to keep LAPPS documents internal to the LAPPS service communication and whenever data is exposed to the user, it is unwrapped and only the payload is handed over? That would entail that a LIF reader wouldn't need to support the wire wrapper because it is not actually part of the format.