You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@taverna.apache.org by Dmitry <re...@list.ru> on 2014/11/26 11:44:53 UTC
SCUFL2 'wrappedType' namespaces question (splitters)
Hello,
JSON configuration for the splitter activities has embedded XML chunks
that suppose to represent a kinda of XML Schema
(a serialization for the XML chunk).
For instance:
---------------------------------------------------------------------------------------------------------------------
<s:extensions xmlns:s=\"http://org.embl.ebi.escience/xscufl/0.1alpha\">
<s:complextype optional=\"false\" unbounded=\"false\"
typename=\"NCBIBlastpRequest\" name=\"request\" qname=\"request\">
<s:elements>
<s:complextype optional=\"true\" unbounded=\"false\"
typename=\"AminoacidSequence\" name=\"sequence\" qname=\"sequence\">
<s:elements>
<s:basetype optional=\"false\" unbounded=\"false\"
typename=\"Sequence\" name=\"sequence\" qname=\"sequence\" />
...
--------------------------------------------------------------------------------------------------------------------
I see the types have a "qname" attribute, but it lacks a prefix (and
there is no namespaces defined).
As far as I understand, the namespaces are recovered later from the data
descriptions obtained from the WSDL, but from the SCUFL2 format point of
view, is it correct to have the qname without a correct namespace?
Cheers,
Dmitry
Re: SCUFL2 'wrappedType' namespaces question (splitters)
Posted by alaninmcr <al...@googlemail.com>.
On 26/11/2014 15:40, Dmitry wrote:
> Hello,
>
>> One possibility would be that part of the UI configuration of the WSDL
>> activity is the selection of the parts of the XML output that will be
>> exposed as output ports and also the selection of what will be exposed
>> as input ports.
>
> This would require a major changes to the workflow editor.
OK. So evolution :)
[snip]
>> Have you considered how this would influence REST services and also
>> the draft(y) JSON services?
> To be fair, no... Is there any troubles? I think REST doesn't use
> splitters. (???)
Currently no. However, many calls of REST services are followed by calls
to XPath to extract the relevant parts of the response.
Alan
Re: SCUFL2 'wrappedType' namespaces question (splitters)
Posted by Dmitry <re...@list.ru>.
Hello,
> One possibility would be that part of the UI configuration of the WSDL
> activity is the selection of the parts of the XML output that will be
> exposed as output ports and also the selection of what will be exposed
> as input ports.
This would require a major changes to the workflow editor.
I agree that this is one the possibilities and, actually, this is that I
have in mind - since the real XML building will be done in the WSDL
activity - there could be other editor. WSDL activity will just assemble
the XML with Map<xpath, data>.
Moreover - I am using the code from "xml-schema-ui" submitted to github.
The part of "XML tree" is moved into "wsdl-generic" replacing the splitters.
The GUI part may be easily used instead of splitters gui.
> Have you considered how this would influence REST services and also
> the draft(y) JSON services?
To be fair, no... Is there any troubles? I think REST doesn't use
splitters. (???)
On 11/26/2014 4:27 PM, alaninmcr wrote:
> On 26/11/2014 14:33, Dmitry wrote:
>> Hello Stian,
>
> Hello Dmitry and others,
>
>> That is exactly what I am thinking...
>>
>> I am trying to get rid of splitters completely, what is why I got deep
>> into the SCUFL2.
>
> [snip]
>
>> They will still be used by the UI,
>
> You may want to rethink that. One possibility would be that part of
> the UI configuration of the WSDL activity is the selection of the
> parts of the XML output that will be exposed as output ports and also
> the selection of what will be exposed as input ports.
>
> So any XML splitting/assembling would happen (so far as the user is
> concerned) within the WSDL activity.
>
>> but instead of "splitting" (or
>> "assembling") XMLs they are going to collect/generate parameters' data.
>> to correctly associate this data with XML elements (or attributes) every
>> splitter will produce the XPath id (partial) - every "outer" will add an
>> additional path.
>
> Have you considered how this would influence REST services and also
> the draft(y) JSON services?
>
> [snip]
>
>> Cheers,
>>
>> Dmitry
>
> Alan
>
>
Re: SCUFL2 'wrappedType' namespaces question (splitters)
Posted by alaninmcr <al...@googlemail.com>.
On 26/11/2014 14:33, Dmitry wrote:
> Hello Stian,
Hello Dmitry and others,
> That is exactly what I am thinking...
>
> I am trying to get rid of splitters completely, what is why I got deep
> into the SCUFL2.
[snip]
> They will still be used by the UI,
You may want to rethink that. One possibility would be that part of the
UI configuration of the WSDL activity is the selection of the parts of
the XML output that will be exposed as output ports and also the
selection of what will be exposed as input ports.
So any XML splitting/assembling would happen (so far as the user is
concerned) within the WSDL activity.
> but instead of "splitting" (or
> "assembling") XMLs they are going to collect/generate parameters' data.
> to correctly associate this data with XML elements (or attributes) every
> splitter will produce the XPath id (partial) - every "outer" will add an
> additional path.
Have you considered how this would influence REST services and also the
draft(y) JSON services?
[snip]
> Cheers,
>
> Dmitry
Alan
Re: SCUFL2 'wrappedType' namespaces question (splitters)
Posted by Dmitry <re...@list.ru>.
Hello Stian,
That is exactly what I am thinking...
I am trying to get rid of splitters completely, what is why I got deep
into the SCUFL2.
My idea is to remove splitters from "wsdl-generic" completely, but keep
XMLSplitterActivity(ies).
The thing I am trying to do is to use XMLSplitter activities as a
"proxy" sugar.
They will still be used by the UI, but instead of "splitting" (or
"assembling") XMLs they are going to collect/generate parameters' data.
to correctly associate this data with XML elements (or attributes) every
splitter will produce the XPath id (partial) - every "outer" will add an
additional path.
So the execution of the splitter won't generate an output, but rather
add into the map <xpath, data>.
When execution goes to the WSDL Activity, it should map correctly all
these inputs and generate the actual SOAP body.
The main trouble with XPath is that it is not very kind with namespaces.
For instance:
/*[namespace-uri()='http://example.com' and
local-name()='person']/*[namespace-uri()='http://example.com' and
local-name()='name']
is the same as
"/ns0:person/ns0:name" with the namespace context containing 'ns0' =
'http://example.com'.
having the SCUFL without namespaces I'll get just "/person/name", so I
have to invent something to match.
Cheers,
Dmitry
On 11/26/2014 3:11 PM, Stian Soiland-Reyes wrote:
> I think it is caused by parsing the WSDL without forcing attributes to be
> qualified (namespaced).. and so it remains in the default namespace. I
> don't think it's very correct. You might also notice that the xmlns:s
> namespace uses an "escience" TLD which is very wrong.
>
> It's not particularly pretty - I would have rather seen in SCUFL2 that the
> whole XML Schema was captured independently somewhere inside the Workflow
> Bundle and then linked to by a combination of type and schema - but
> obviously when translating from t2flow we don't have that luxury.
>
>
> Changing this would affect the XML splitters a lot - I think it's about due
> time.. how do you "carry on" the schema in your alternative approach? That
> is the main reason the schema is coming along inside the config - so that
> you can add further splitters and so that the splitter works independently
> of its original web service. (... but this also mean that it easily
> becomes outdated if that webservice changes its schema)
>
>
> On 26 November 2014 at 10:44, Dmitry <re...@list.ru> wrote:
>
>> Hello,
>>
>> JSON configuration for the splitter activities has embedded XML chunks
>> that suppose to represent a kinda of XML Schema
>> (a serialization for the XML chunk).
>>
>> For instance:
>> ------------------------------------------------------------
>> ---------------------------------------------------------
>> <s:extensions xmlns:s=\"http://org.embl.ebi.escience/xscufl/0.1alpha\">
>> <s:complextype optional=\"false\" unbounded=\"false\"
>> typename=\"NCBIBlastpRequest\" name=\"request\" qname=\"request\">
>> <s:elements>
>> <s:complextype optional=\"true\" unbounded=\"false\"
>> typename=\"AminoacidSequence\" name=\"sequence\" qname=\"sequence\">
>> <s:elements>
>> <s:basetype optional=\"false\" unbounded=\"false\"
>> typename=\"Sequence\" name=\"sequence\" qname=\"sequence\" />
>> ...
>> ------------------------------------------------------------
>> --------------------------------------------------------
>>
>> I see the types have a "qname" attribute, but it lacks a prefix (and there
>> is no namespaces defined).
>> As far as I understand, the namespaces are recovered later from the data
>> descriptions obtained from the WSDL, but from the SCUFL2 format point of
>> view, is it correct to have the qname without a correct namespace?
>>
>> Cheers,
>>
>> Dmitry
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating)
>> http://orcid.org/0000-0001-9842-9718
>>
Re: SCUFL2 'wrappedType' namespaces question (splitters)
Posted by Stian Soiland-Reyes <st...@apache.org>.
I think it is caused by parsing the WSDL without forcing attributes to be
qualified (namespaced).. and so it remains in the default namespace. I
don't think it's very correct. You might also notice that the xmlns:s
namespace uses an "escience" TLD which is very wrong.
It's not particularly pretty - I would have rather seen in SCUFL2 that the
whole XML Schema was captured independently somewhere inside the Workflow
Bundle and then linked to by a combination of type and schema - but
obviously when translating from t2flow we don't have that luxury.
Changing this would affect the XML splitters a lot - I think it's about due
time.. how do you "carry on" the schema in your alternative approach? That
is the main reason the schema is coming along inside the config - so that
you can add further splitters and so that the splitter works independently
of its original web service. (... but this also mean that it easily
becomes outdated if that webservice changes its schema)
On 26 November 2014 at 10:44, Dmitry <re...@list.ru> wrote:
> Hello,
>
> JSON configuration for the splitter activities has embedded XML chunks
> that suppose to represent a kinda of XML Schema
> (a serialization for the XML chunk).
>
> For instance:
> ------------------------------------------------------------
> ---------------------------------------------------------
> <s:extensions xmlns:s=\"http://org.embl.ebi.escience/xscufl/0.1alpha\">
> <s:complextype optional=\"false\" unbounded=\"false\"
> typename=\"NCBIBlastpRequest\" name=\"request\" qname=\"request\">
> <s:elements>
> <s:complextype optional=\"true\" unbounded=\"false\"
> typename=\"AminoacidSequence\" name=\"sequence\" qname=\"sequence\">
> <s:elements>
> <s:basetype optional=\"false\" unbounded=\"false\"
> typename=\"Sequence\" name=\"sequence\" qname=\"sequence\" />
> ...
> ------------------------------------------------------------
> --------------------------------------------------------
>
> I see the types have a "qname" attribute, but it lacks a prefix (and there
> is no namespaces defined).
> As far as I understand, the namespaces are recovered later from the data
> descriptions obtained from the WSDL, but from the SCUFL2 format point of
> view, is it correct to have the qname without a correct namespace?
>
> Cheers,
>
> Dmitry
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating)
> http://orcid.org/0000-0001-9842-9718
>