Hi,

We are using Tamino 3.1.1.1 on Windows.

When trying to insert a TXMLObject containing xhtml, we receive the following error:

NestedException:Tamino access failure (INOXDE7763: An invalid value has been found during validation., Line 1, Column 583: datatype validation for attribute “item-type” of type xs:integer failed:

The XML we are trying to insert is as follows:

<custom-meta-4117-16 item-id="4118" item-type="16">
<textcomp>text comp</textcomp><mmlink>tcm:40-4024</mmlink>
<MetaEmbed>
<EmTextTwo>Text two</EmTextTwo>
<EmNumber3>3333</EmNumber3>
<EmDate1>2003-11-04T15:29:00</EmDate1>
<EmDate2>2003-11-12T15:30:00</EmDate2>
<EmExtLink1>http://www.thislinx.nl</EmExtLink1>
<EmExtLink2>http://anotherone.com</EmExtLink2>
<EmEmbed>
<EmTextOne>embedded text 1</EmTextOne>
<EmNumber1>1111</EmNumber1>
<EmNumber2>222</EmNumber2>
<EmTextCat>key1</EmTextCat>
<EmComplink1>tcm:40-4016</EmComplink1>
</EmEmbed>
<EmbeddedFormatText>
<xhtml:strong>
<xhtml:font color="#0000ff" face="Arial" size="6" style="BACKGROUND-COLOR: #ffff00">
And this is really formatted As Well
</xhtml:font>
</xhtml:strong>
</EmbeddedFormatText>
</MetaEmbed></custom-meta-4117-16>

(If you can’t read this, see the attached file).
The error message seems to suggest that the XML parser is gobbling up all of the content between the start of ID and the first xhtml element with an attribute.

Is this a known issue with Tamino 3.1.1.1, or am I doing something wrong. The schema being used for this has an xs:any element defined where the XHTML is.

Thanks for any suggestions you have,

David

[This message was edited by Admin on 13 Nov 2003 at 10:31.]
xml_and_errormessage.txt (1.05 KB)

hi emmet,

three points:

a) does this error occur only when you insert the document with the API? please check by inserting the document “manually” for example with the interactive interface.

b) if applicable, you might want to provide the schema here, too.

c) technically, tamino 3.1.1.1 has gone out of maintenance some time ago, so you may
want to consider upgrading to a more recent version anyways

hope this helps,

andreas f.

Hi Andreas,

thanks for your reply:

a). Yes this happens when I do this with the interactive interface. I get the same error, which is what makes me think this may actually be caused by something in Tamino 3.1.1.1 itself (the phrase ‘greedy regular expression’ was the first thing that came to mind when I saw this happen).

b) Here is the schema I’m using:
<?xml version = "1.0" encoding = "UTF-8"?>
<xs:schema xmlns:xs = “XML Schema” xmlns:tsd = “http://namespaces.softwareag.com/tamino/TaminoSchemaDefinition”>
xs:annotation
xs:documentationDTD for doctype ComponentMetaData.</xs:documentation>
xs:appinfo
<tsd:schemaInfo name = “custom-meta-4122-16”>
<tsd:collection name = “pub40”></tsd:collection>
<tsd:doctype name = “custom-meta-4122-16”>
tsd:logical
tsd:contentclosed</tsd:content>
</tsd:logical>
</tsd:doctype>
tsd:adminInfo
tsd:created2003-11-12T13:18:47.750+01:00</tsd:created>
tsd:modified2003-11-12T13:18:47.750+01:00</tsd:modified>
tsd:versionTSD3</tsd:version>
</tsd:adminInfo>
</tsd:schemaInfo>
</xs:appinfo>
</xs:annotation>
xs:annotation
xs:appinfo
tsd:schemaInfo
tsd:adminInfo
tsd:versionTSD3</tsd:version>
tsd:created2003-11-12T13:18:47.750+01:00</tsd:created>
tsd:modified2003-11-12T13:18:47.750+01:00</tsd:modified>
</tsd:adminInfo>
</tsd:schemaInfo>
</xs:appinfo>
</xs:annotation>
<xs:element name = “custom-meta-4122-16”>
xs:complexType
xs:sequence
<xs:element name = “textcomp” type = “xs:normalizedString”></xs:element>
<xs:element name = “mmlink”></xs:element>
<xs:element name = “MetaEmbed”>
xs:complexType
xs:sequence
<xs:element name = “EmTextTwo” type = “xs:normalizedString”></xs:element>
<xs:element name = “EmNumber3” type = “xs:decimal”></xs:element>
<xs:element name = “EmDate1” type = “xs:dateTime”></xs:element>
<xs:element name = “EmDate2” type = “xs:dateTime” maxOccurs = “unbounded”></xs:element>
<xs:element name = “EmExtLink1”></xs:element>
<xs:element name = “EmExtLink2” maxOccurs = “unbounded”></xs:element>
<xs:element name = “EmEmbed” minOccurs = “0”>
xs:complexType
xs:sequence
<xs:element name = “EmTextOne” type = “xs:normalizedString”></xs:element>
<xs:element name = “EmNumber1” type = “xs:decimal”></xs:element>
<xs:element name = “EmNumber2” type = “xs:decimal” maxOccurs = “unbounded”></xs:element>
<xs:element name = “EmTextCat” minOccurs = “0”></xs:element>
<xs:element name = “EmComplink1”></xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name = “EmbeddedFormatText” minOccurs = “0”>
xs:complexType
xs:sequence
<xs:any namespace = “##any” processContents = “skip” minOccurs = “0” maxOccurs = “unbounded”></xs:any>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name = “item-id” type = “xs:integer” use = “required”></xs:attribute>
<xs:attribute name = “item-type” type = “xs:integer” use = “required”></xs:attribute>
</xs:complexType>
</xs:element>
</xs:schema>

c) I realise that support is ended / about to end for Tamino 3.1.1.1. Ironically, my next project, after fixing this bug, will be to port our application to support Tamino 4.1. However, if I can fix this, I would like to. If it is a problem with Tamino 3.1.1.1, then I can move on to test this against 4.1. So, if anybody has any ideas, I would be grateful.

Thanks

David
custom-meta-4122-16.TSD (3.26 KB)

hi david,

1) i was able to reproduce your issue on 3111 - you decide whether this is good news or bad news.

2) definitely good news: after adding a namespace declaration to the document, i was able to insert it into a 4.1.4.3 database.

this may not help you for the current project but at least it works in future tamino version.

hope this helps,

andreas f.

Hi Andreas,

Thanks a lot for your help. I am glad you have been able to reproduce this issue, as this means it is not just me…

I have also been able to provide a workaround for this problem (don’t use xhtml in this situation), and have found that this problem does not occur in Tamino 4.1.x, so when we get around to upgrading, then this will be fixed.

Thanks again for your effort,

David