How must be the SOAP schema for Tamino 4.1.1 ?

Hello everybody,

I am trying to define a schema into Tamino in order to make log of SOAP documents received and managed by EntireX XML Mediator.

The one attached I downloaded from this forum, but when I try to save a SOAP document, I receive this response from Tamino:

<?xml version="1.0" encoding="windows-1252" ?>
<ino:response xmlns:ino=“http://namespaces.softwareag.com/tamino/response2” xmlns:xql=“http://metalab.unc.edu/xql/”>
<ino:message ino:returnvalue=“0”>
ino:messagelinedocument processing started</ino:messageline>
</ino:message>
<ino:message ino:returnvalue=“7781”>
<ino:messagetext ino:code=“INOXDE7781”>Invalid or unsupported attribute found.</ino:messagetext>
</ino:message>
</ino:response>

Documents I am using are been generated by EntireX Workbench, and the parameters included have a type attribute with xsi prefix. The error seems to be referred to this prefix.

How can I define a schema for SOAP documents?, and for signed SOAP documents?

Thanks in advance,

Rosa.
envelopes.TSD (2.21 KB)

Nodoby did that ? does anybody save SOAP documents in TSD4 ?

I need to save this kind of documents, and now I have to take off the xsi prefix in type attributes with a stylesheet.

Any help will be welcome. Thank you.

Rosa.

Rosa,

I could define your schema without any changes to Tamino 4.
Which Tamino version do you use?

Hello,

Tamino XML Server 4.1.1.

Yes, I can define the schema, the problem is when I try to save or load some document, like the one attached, e.g. generated by EntireX Communicator, then I receive this response from Tamino, without success saving document:

<?xml version="1.0" encoding="windows-1252" ?>
<ino:response xmlns:ino=“http://namespaces.softwareag.com/tamino/response2” xmlns:xql=“http://metalab.unc.edu/xql/”>
<ino:message ino:returnvalue=“0”>
ino:messagelinedocument processing started</ino:messageline>
</ino:message>
<ino:message ino:returnvalue=“7781”>
<ino:messagetext ino:code=“INOXDE7781”>Invalid or unsupported attribute found.</ino:messagetext>
</ino:message>
</ino:response>

And when I delete xsi prefix from type attributes in request document, then Tamino save the document.
The question is, why do I have to delete this prefix in type attributes? At the moment I can’t save documents as they are, imagine saving signed docs, what do I have to do? Do I have to modify them in order to save in Tamino?
Perhaps I am not using an appropiate shema, isn’t it?

Thanks,

Rosa.

[This message was edited by Rosa on 31 Mar 2003 at 09:18.]

[This message was edited by Rosa on 31 Mar 2003 at 09:55.]
calc-envelope.xml (747 Bytes)

The xsi:type attribute (with xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”) as described in http://www.w3.org/TR/xmlschema-1/#xsi_type is currently rejected by Tamino 4.1 for the following reason:
xsi:type is intended to enforce that an element’s or attribute’s value or content is validated vs. a type which differs from the one defined in the respective schema. Unfortunately, Tamino does not yet support this functionality. If Tamino would accept XML documents containing xsi:type by now, we would end up with an inconsistent database state as documents are stored in Tamino which never have been validated against the respective schema in the way described in the XML schema spec.

Ulrich,

I’m afraid your explanation doesn’t hold water. Since the xsi:type attribute is found as a child of the Body element in the schema (i.e. matching the “Any” element), shouldn’t Tamino simply accept “any” children of the Body element without further validation? I ran into Rosa’s problem myself and couldn’t figure out what to do before stumbling upon this thread.

How else can we store documents with unexpected namespaces if the “Any” element type doesn’t allow “any” element? Seems to me this is a bug.

Hi Ned
the XML Schema Spec contains some special sections (and requires some careful reading)
regarding xsi:type with wildcards - in that context xsi:type is special! It is not like any arbitrary attribute just from another namespace - see e.g. http://www.w3.org/TR/xmlschema-1/#Wildcard_details, description of “strict”.

… (sorry - last contribution was not yet complete)
In addition, I do not claim that the implementation in Tamino 4.1 is already
conformant with XML Schema: we just decided to reject xsi:type always,
otherwise we might run into migration issues with respect to future versions
of Tamino.

Cheers
Uli

So if I am hearing you correctly, the only way Tamino can store a SOAP document which contains the xsi namespace is to REMOVE this namespace? Do the developers realize how frequently this namespace is used in a SOAP document?

Hi,

> So if I am hearing you correctly, the only way Tamino can store a SOAP document which contains the xsi namespace is to REMOVE this namespace?

This is true in the current version of Tamino (but see below). The reason is that up to version 4.1.4, Tamino cannot do validation based in xsi:type, i.e. acceptance of such documents could imply to store invalid documents. This will change with version 4.2, which will accept xsi:type attributes if the document is valid under the types specified.

> Do the developers realize how frequently this namespace is used in a SOAP document?
We do. And there is one remedy if the acceptance of xsi:type is really urgently needed in a customer environment.
Should this be the case, please contact Tamino Product Management.

regards

Harald