Datalength

Question

I am having trouble with iFS accepting instances with attributes of arbitrary length. In the example instances below, I would like the COVER attribute to contain data of any length. In this case, I have tried to achieve this be omitting the Datalength tag from the attribute in the type definition. In the valid instance below, the <COVER> tag holds the maximum number of characters allowable. In the invalid instance, the <COVER> tag is over the allowable character length, so the following error displays:
ifs-30002: Unable to create new libraryObject.
Maximum allowable characters within attribute:
My question is this: How do I indicate in the doc type definition that I do not want length constraints put on an attribute string?
My Doc Type Definition:
<?xml version="1.0" standalone="yes" ?>
<ClassObject>
<name>PropTypeLite1</name>
<Description>Simple Demo of Prop Pilot 1</Description>
<Superclass RefType="name">
Document
</Superclass>
<Attributes>
<Attribute>
<Name>Title</Name>
<DataType>String</DataType>
<Datalength>128</Datalength>
</Attribute>
<Attribute>
<Name>Client</Name>
<DataType>String</DataType>
<Datalength>128</Datalength>
</Attribute>
<Attribute>
<Name>Cover</Name>
<DataType>String</DataType>
</Attribute>
</Attributes>
</ClassObject>
My Valid Instance of PropTypeLite1:
<?xml version = '1.0' standalone = 'yes'?>
<PROPTYPELITE1>
<Name>BrookTrout.xml</Name>
<TITLE>Modest Proposal</TITLE>
<CLIENT>Moby Dick</CLIENT>
<COVER>The main disadvantage of WBT is xxxxxxxxx. WBT generally should
not include video, heavy audio, or large graphics that would take too long
to download. We generally work to design each page of WBT to download within
a few seconds over a 28.8 modem. Generally speaking, a 28.8 connection is not
fast enough to support video, advanced graphics, or much interactivity. We can use
the most advanced streaming technology to try to fend off these concerns, but still
have far more restrictions on a course that runs over a live connection.
The main disadvantage of WBT is bandwidth. WBT generally should
not include video, heavy audio, or large graphics that would take too long
to download. The main disadvantage of WBT is bandwidth. WBT generally should
not include video, heavy audio, or large graphics that would take too long
to download. The main disadvantage of WBT is bandwidth.
The main disadvantage of WBT is bandwidth. The main disadvantage.
The main disa</COVER>
</PROPTYPELITE1>
My Invalid Instance of PropTypeLite1 (note extending datalength of COVER attribute makes this instance invalid):
<?xml version = '1.0' standalone = 'yes'?>
<PROPTYPELITE1>
<Name>BrookTrout.xml</Name>
<TITLE>Modest Proposal</TITLE>
<CLIENT>Moby Dick</CLIENT>
<COVER>The main disadvantage of WBT is xxxxxxxxx. WBT generally should
not include video, heavy audio, or large graphics that would take too long
to download. We generally work to design each page of WBT to download within
a few seconds over a 28.8 modem. Generally speaking, a 28.8 connection is not
fast enough to support video, advanced graphics, or much interactivity. We can use
the most advanced streaming technology to try to fend off these concerns, but still
have far more restrictions on a course that runs over a live connection.
The main disadvantage of WBT is bandwidth. WBT generally should
not include video, heavy audio, or large graphics that would take too long
to download. The main disadvantage of WBT is bandwidth. WBT generally should
not include video, heavy audio, or large graphics that would take too long
to download. The main disadvantage of WBT is bandwidth.
The main disadvantage of WBT is bandwidth. The main disadvantage.
The main disa xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx xxxxxxx</COVER>
</PROPTYPELITE1>

Answer 1

Thanks, Mark. As you may already know, ArborText has released an authoring tool called Epic that works in tandem with iFS. Epic is geared for creating large, usually technical, documents. It would seem that the limit to the max String length would pose a serious problem for such a system, especially if large, flat-structured paragraphs are involved.
As you have noted, only one Content tag may be used per instance, so this is not a viable option for large documents. Do you have any thoughts as to how Arbortext has, apparently, gotten around this max length limit? Or more to the point, how can I?
--Thanks